|
|
CVE-ID | ||
---|---|---|
CVE-1999-0345 |
• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information
|
|
Description | ||
Jolt ICMP attack causes a denial of service in Windows 95 and Windows NT systems. | ||
References | ||
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete. | ||
Assigning CNA | ||
MITRE Corporation | ||
Date Record Created | ||
19990607 | Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE. | |
Phase (Legacy) | ||
Proposed (19990728) | ||
Votes (Legacy) | ||
ACCEPT(2) Blake, Cole MODIFY(2) Frech, Wall NOOP(4) Bishop, Landfield, Northcutt, Ozancin RECAST(1) Meunier REJECT(4) Armstrong, Baker, LeBlanc, Levy REVIEWING(1) Christey |
||
Comments (Legacy) | ||
Wall> Invalid ICMP datagram fragments causes a denial of service in Windows 95 and Windows NT systems. Reference: Q154174. Jolt is also known as sPING, ICMP bug, Icenewk, and Ping of Death. It is a modified teardrop 2 attack. Frech> XF:nt-ssping ADDREF XF:ping-death ADDREF XF:teardrop-mod ADDREF XF:mpeix-echo-request-dos Christey> I can't tell whether the Jolt exploit at: http://www.securityfocus.com/templates/archive.pike?list=1&date=1997-06-28&msg=Pine.BSF.3.95q.970629163422.3264A-200000@apollo.tomco.net is exploiting any different flaw than teardrop does. CHANGE> [Christey changed vote from NOOP to REVIEWING] Baker> Jolt (original) is basically just a fragmented oversized ICMP that kills Win boxes ala Ping of Death. Teardrop is altering the offset in fragmented tcp packets so that the end of subsequent fragments is inside first packet... Teardrop 2 is UDP packets, if I remember right. Seems like Jolt (original, not jolt 2) is just exploit code that creates a ping of death (CVE 1999-0128) Levy> I tend to agree with Baker. CHANGE> [Armstrong changed vote from REVIEWING to REJECT] Armstrong> This code does not use fragment overlap. It is simply a large ICMP echo request. Christey> See the SCO advisory at: http://www.securityfocus.com/templates/advisory.html?id=1411 which may further clarify the issue. LeBlanc> This is a hodge-podge of DoS attacks. Jolt isn't the same thing as ping of death - POD was an oversized ICMP packet, Jolt froze Linux and Solaris (and I think not NT), IIRC Jolt2 did get NT boxes. Teardrop and teardrop2 were related attacks (usually ICMP frag attacks), but each of these is a distinct vulnerability, affected a discrete group of systems, and should have distinct CVE numbers. CVE entries should be precise as to what the problem is. Meunier> I agree with Leblanc in that Jolt is multi-faceted. Jolt has characteristics of Ping of Death AND teardrop, but it doesn't do either exactly. Moreover, it sends a truncated IP fragment. I disagree with Armstrong; jolt uses overlapping fragments. It's not a simple ping of death either. It may be that the author's intent was to construct a "super attack" somehow combining elements of other vulnerabilities to try to make it more potent. In any case it succeeded in confusing the CVE board :-). I notice that Jolt uses echo replies (type 0) instead of echo requests (to get past firewalls?). Jolt is peculiar in that it also sends numerous overlapping fragments. The "Pascal Simulator" :-) says it sends: - 172 fragments of length 400 with offset starting at 5120 and increasing by about 47 (odd arithmetic of 5120 OR ((n* 380) > > 3)), which eventually results in sending fragments inside an already covered area once ((n* 380) > > 3) is greater than 5120, which occurs when n is reaches 108. This would look a bit like TearDrop if fragments were reassembled on-the-fly. - 1 fragment such that the total length of all the fragments is greater than 65535 (my calculation is 172*380 + 418 = 65778; the comment about 65538 must be wrong). The last packet is size 418 according to the IP header but the buffer is of size 400. The sendto takes as argument the size of the buffer so a truncated packet is sent. So, I am not sure if the problem is because the last packet doesn't extend to the payload it says it has or because the total size of all fragments is greater than 65535. The author says it may take more than one sending, so perhaps this has to do with an incorrect error handling and recovery. One would need to experiment and isolate each of those characteristics and test them independently. Inasmuch as each of those things is likely a different vulnerability, then I agree with Leblanc that this entry should be split. I'll try that if I ever get bored. Jolt 2 should also have a different entry (see below). Jolt 2 runs in an infinite loop, sending the same fragmented IP packet, which can pretend to be "ICMP" or "UDP" data; however this is meaningless, as it's just a late fragment of an IP packet. The attack works only as long as packets are sent. According to http://www.securityfocus.com/archive/1/62170 the packets are truncated, and would overflow over the 65535 byte limit, which is similar to Jolt. Note that Jolt does send that much data whereas jolt2 doesn't. Since jolt2 is simpler and narrower than jolt, and it has weaker consequences, I believe that it's a different vulnerability. "Jolt 2 vulnerability causes a temporary denial-of-service in Windows-type OSes" would be a title for it. |
||
Proposed (Legacy) | ||
19990728 | ||
This is an record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities. | ||
You can also search by reference using the CVE Reference Maps.
|
||
For More Information: CVE Request Web Form (select "Other" from dropdown) |