Realsecure DoS Attack Subversion Vulnerability
BID:1022
Info
Realsecure DoS Attack Subversion Vulnerability
| Bugtraq ID: | 1022 |
| Class: | Failure to Handle Exceptional Conditions |
| CVE: | |
| Remote: | Yes |
| Local: | Yes |
| Published: | Mar 01 2000 12:00AM |
| Updated: | Mar 01 2000 12:00AM |
| Credit: | This vulnerability was discovered by Stephane AUBERT <[email protected]> and posted to the Bugtraq mailing list on February 29, 2000. |
| Vulnerable: |
Internet Security Systems RealSecure 3.2.1999 Internet Security Systems RealSecure 3.2 Internet Security Systems RealSecure 3.1 Internet Security Systems RealSecure 3.0 |
| Not Vulnerable: | |
Discussion
Realsecure DoS Attack Subversion Vulnerability
Under some versions of Internet Security Systems RealSecure Network Intrusion Detection software it is possible for attackers to launch a series of IP Fragment based denial of service (DoS) attacks without the software detecting them as it should.
This is due to the software relying on packet signatures which if slightly changed will not be flagged as attacks. The attack in question is the Teardrop DoS and modifications thereof. In particular the SynDrop, NewTear and Targa attacks.
The Teardrop denial of service attack exploits a flaw inherent to multiple vendor TCP/IP stacks. This problem is related to how the TCP/IP stack handle reassembly of fragmented IP packets.
This attack can be delivered by sending 2 or more specially fragmented IP datagrams. The first is the 0 offset fragment with a payload of size N, with the MF bit on (data content is irrelevant). The second is the last fragment (MF == 0) with a positive offset < N and with a payload of < N.
This results in the TCP/IP stack allocating unusually large resources to reassembling the packet(s). Depending on the memory deployed on the target box this usually results in the system freezing due to insufficient memory or in some case causing the machine to reboot.
Under some versions of Internet Security Systems RealSecure Network Intrusion Detection software it is possible for attackers to launch a series of IP Fragment based denial of service (DoS) attacks without the software detecting them as it should.
This is due to the software relying on packet signatures which if slightly changed will not be flagged as attacks. The attack in question is the Teardrop DoS and modifications thereof. In particular the SynDrop, NewTear and Targa attacks.
The Teardrop denial of service attack exploits a flaw inherent to multiple vendor TCP/IP stacks. This problem is related to how the TCP/IP stack handle reassembly of fragmented IP packets.
This attack can be delivered by sending 2 or more specially fragmented IP datagrams. The first is the 0 offset fragment with a payload of size N, with the MF bit on (data content is irrelevant). The second is the last fragment (MF == 0) with a positive offset < N and with a payload of < N.
This results in the TCP/IP stack allocating unusually large resources to reassembling the packet(s). Depending on the memory deployed on the target box this usually results in the system freezing due to insufficient memory or in some case causing the machine to reboot.
Exploit / POC
Realsecure DoS Attack Subversion Vulnerability
The following excerpt from the original post on this subject (which is located in the 'Credit' section of this entry) details how an attacker might launch these attacks successfully:
"For example, the original/public teardrop.c version exploits the overlapping IP fragment bug by sending 2 IP fragments. The ID field of the 2 IP fragments is not involved in the attack and was fixed to 242 (why not ? ;-) ):
*((u_short *)p_ptr) = htons(242); /* IP id */
By changing this value from 242 to 666 (it can be a random number), RealSecure won't detect teardrop attacks."
The following excerpt from the original post on this subject (which is located in the 'Credit' section of this entry) details how an attacker might launch these attacks successfully:
"For example, the original/public teardrop.c version exploits the overlapping IP fragment bug by sending 2 IP fragments. The ID field of the 2 IP fragments is not involved in the attack and was fixed to 242 (why not ? ;-) ):
*((u_short *)p_ptr) = htons(242); /* IP id */
By changing this value from 242 to 666 (it can be a random number), RealSecure won't detect teardrop attacks."
Solution / Fix
Realsecure DoS Attack Subversion Vulnerability
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Internet Security Systems was notified of this problem on February 14, 2000. Their response was as follows:
"Thanks for your in depth analysis of our RealSecure Teardrop signature. We rarely get such detailed reports and they are very much appreciated. Now that we are aware of the issue, we've logged this as a bug so we can address it in an upcoming release.
We haven't tested RealSecure against Whisker, but now that brought this to our attention we can add it to our product test plan. We work very hard to test our products against as many known attacks as possible and information like this allows us to improve our test plan with every release.
Please feel free to provide us feedback like this in the future as it helps us make a better product for all our customers."
Solution:
Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Internet Security Systems was notified of this problem on February 14, 2000. Their response was as follows:
"Thanks for your in depth analysis of our RealSecure Teardrop signature. We rarely get such detailed reports and they are very much appreciated. Now that we are aware of the issue, we've logged this as a bug so we can address it in an upcoming release.
We haven't tested RealSecure against Whisker, but now that brought this to our attention we can add it to our product test plan. We work very hard to test our products against as many known attacks as possible and information like this allows us to improve our test plan with every release.
Please feel free to provide us feedback like this in the future as it helps us make a better product for all our customers."