📄 351.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>apue</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="309.htm">上一层</a>][<a href="352.htm">下一篇</a>]
<hr><p align="left"><small>发信人: toby (无意识), 信区: Hacker <br>
标 题: jolt2-analysis.txt <br>
发信站: 华南网木棉站 (Thu Jun 8 18:27:19 2000), 转信 <br>
发信站: 华南网木棉站 (Thu Jun 8 18:27:19 2000), 转信 <br>
<br>
<br>
<br>
------------------------------------------------------------------ <br>
<br>
Subject: Analysis of jolt2.c <br>
<br>
Date: 2000-05-26 (revision 1) <br>
<br>
2000-05-27 (revision 2) <br>
<br>
Author: Mikael Olsson, EnterNet Sweden <mikael.olsson@enternet.se> <br>
<br>
<br>
<br>
Sent to: firewalls@lists.gnac.net <br>
<br>
firewall-wizards@nfr.net <br>
<br>
<br>
bugtraq@securityfocus.com <br>
<br>
win2ksecadvice@listserv.ntsecurity.net (not subscribed!) <br>
<br>
------------------------------------------------------------------ <br>
<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------ <br>
<br>
FOREWORD <br>
<br>
------------------------------------------------------------------ <br>
<br>
<br>
<br>
I decided to release this update after being flamed by several <br>
<br>
people telling me just how wrong I am, and that I should "check <br>
<br>
<br>
my facts" before posting. <br>
<br>
<br>
<br>
Note, however, that I _did_ check my facts. <br>
<br>
All I did was analyze the "jolt2.c" code as presented, which <br>
<br>
means I had the facts right in front of me. <br>
<br>
<br>
<br>
Reportedly, this code snippet is not the same code used as <br>
<br>
in finding the vulnerability. Hence, I'm theorizing quite <br>
<br>
a bit and freely questioning the results. <br>
<br>
<br>
<br>
This update contains a few corrections (snafus on my part) <br>
<br>
<br>
aswell as comments from other people, mainly Phonix, who <br>
<br>
wrote the proof-of-concept snippet "jolt2.c". <br>
<br>
<br>
<br>
------------------------------------------------------------------ <br>
<br>
ANALYSIS OF JOLT2.C (attached) <br>
<br>
------------------------------------------------------------------ <br>
<br>
<br>
<br>
There are two modes of operation: <br>
<br>
- Illegaly fragmented ICMP ECHOs (pings) <br>
<br>
- Illegaly fragmented UDP packets <br>
<br>
<br>
<br>
<br>
They both send out a continous stream of identical <br>
<br>
fragments (same offset, same frag ID, same everything) <br>
<br>
where the fragments are constructed such that: <br>
<br>
<br>
<br>
- ALL fragments are sent with fragment offset 65520. <br>
<br>
(REVISED: I found this snafu myself. The value transmitted <br>
<br>
is 8190, but this is the number of 64-bit blocks, so the <br>
<br>
real offset is 65520.) <br>
<br>
- 9 bytes of IP data are sent (total packet length 29) <br>
<br>
- IP packet ID is 0x0455 <br>
<br>
- TTL is initially 255 <br>
<br>
<br>
- Source address is not spoofed <br>
<br>
- Destination address is victim address <br>
<br>
or "ICMP" data. It is NOT sending a specific ICMP type, <br>
<br>
and it is NOT sending to a specific UDP port! <br>
<br>
<br>
<br>
Phonix <phonix@moocow.org> wrote: <br>
<br>
> The code was taken from other places as a proof-of-concept. <br>
<br>
> Had the code needed to be pretty, it would have been. <br>
<br>
<br>
<br>
Point taken, Phonix :-) <br>
<br>
<br>
<br>
The ICMP header sent is an ICMP ECHO (ping) with <br>
<br>
code=0 <br>
<br>
checksum=0 <br>
<br>
unused 32-bit value = 0 <br>
<br>
the one data byte = 0 <br>
<br>
<br>
<br>
The UDP header sent has dest port = user-specified, <br>
<br>
src port = user-specified (binary OR) 1235 <br>
<br>
checksum = 0 <br>
<br>
UDP total length = 9 <br>
<br>
<br>
the one data byte = 'a' <br>
<br>
<br>
<br>
Again: No one will parse these headers, it's just <br>
<br>
"another 9 bytes of data". <br>
<br>
In the source, the IP checksum is set to zero. I incorrectly <br>
<br>
took this to mean that it won't propagate across routers, and <br>
<br>
that the MS IP stack accepts them even though the checksum <br>
<br>
is invalid. However: <br>
<br>
<br>
<br>
Phonix <phonix@moocow.org> wrote: <br>
<br>
> By the way, setting the checksum to 0 is perfectly valid <br>
<br>
<br>
> if you are offloading the checksumming to the NIC. <br>
<br>
<br>
<br>
The code never mentioned this, and I failed to think of it. <br>
<br>
However : <br>
<br>
<br>
<br>
Phonix <phonix@moocow.org> wrote: <br>
<br>
> I haven't verified that it works with 0 checksums out <br>
<br>
> on the wire. <br>
<br>
<br>
<br>
If someone can verify that the problem still exists when <br>
<br>
checksums are _transmitted_ as zero, we'd all be grateful. <br>
<br>
<br>
This would illustrate an even worse failing in the MS <br>
<br>
stack. According to RFC1812, the only action taken <br>
<br>
on a packet before the checksum check should be to verify <br>
<br>
that it is large enough to contain the basic IP header. <br>
<br>
(Flames begone! I said "would"!) <br>
<br>
<br>
<br>
<br>
<br>
In reading the code, I noticed that there is no rate <br>
<br>
limit on the fragments sent. Rather, it sends an unlimited <br>
<br>
stream of fragments as fast as the sender can handle. <br>
<br>
<br>
<br>
<br>
I originally thought that this _may_ be proof of another <br>
<br>
problem - What if _this_ code isn't exploiting a fragmentation <br>
<br>
vulnerability, but rather a network layer resource exhaustion <br>
<br>
vulnerability? The net results could be the same (CPU and RAM <br>
<br>
crunching), but be caused by entirely different reasons. <br>
<br>
<br>
<br>
Several people have told (flamed?) me that I am completely wrong, <br>
<br>
simply because the Microsoft and Bindview advisories state <br>
<br>
that it is a fragmentation problem. <br>
<br>
<br>
<br>
This does not change the facts however. I would _really_ <br>
<br>
<br>
like to see this code (jolt2.c) have the same results <br>
<br>
_WITH_ rate limiting implemented before I blindly accept <br>
<br>
the results. (I'm not saying anyone is lying here, I just <br>
<br>
like seeing proof before accepting something as facts.) <br>
<br>
<br>
<br>
<br>
<br>
Again, analyzing the structure of the fragments. <br>
<br>
<br>
<br>
- The data _sent_ is 29 bytes (20 IP + 9 data), which is valid <br>
<br>
as it is a last fragment (MF=0). <br>
<br>
<br>
<br>
<br>
- However, the total length reported by the IP header is 68 <br>
<br>
bytes. This means that the packet should fail structural <br>
<br>
tests, if there are any. [snip poisonous statement about <br>
<br>
A Large OS Vendor's code quality] <br>
<br>
Receipt of a packet with a reported length being larger <br>
<br>
than the actual received length is a normal occurence, <br>
<br>
it'll happen any time a packet is truncated during transport. <br>
<br>
<br>
<br>
- According to the IP header total length, the amount of <br>
<br>
IP data is 48 bytes. Since the offset is 65520, this would <br>
<br>
result in a IP packet length overflow; the maximum allowed <br>
<br>
<br>
length is 65535. <br>
<br>
Note however that the data sent (9 bytes) would not cause <br>
<br>
rather than a fragmentation attack. (NOTE! THIS IS JUST <br>
<br>
A THEORY! I WOULD HAPPILY BE PROVEN WRONG HERE, BUT PLEASE <br>
<br>
PROVIDE PROOF RATHER THAN JUST FLAME ME!) <br>
<br>
<br>
<br>
I can see how 1) could cause problems. If there is some sort <br>
<br>
of garbage collection mechanism, it would attempt to find <br>
<br>
the "oldest" reassembly attempt and discard it when resources <br>
<br>
are running low. However, all fragments belong to the <br>
<br>
same reassembly. So, if the garbage collection routine isn't <br>
<br>
<br>
able to detect that there's something fishy with the "current" <br>
<br>
reassembly and discard IT, we'd get resource exhaustion. <br>
<br>
------------------------------------------------------------------ <br>
<br>
REFERENCES <br>
<br>
------------------------------------------------------------------ <br>
<br>
<br>
<br>
The below header comes from jolt2.c: <br>
<br>
<br>
<br>
/* <br>
<br>
* File: jolt2.c <br>
<br>
* Author: Phonix <phonix@moocow.org> <br>
<br>
<br>
* Date: 23-May-00 <br>
<br>
* <br>
<br>
* Description: This is the proof-of-concept code for the <br>
<br>
* Windows denial-of-serice attack described by <br>
<br>
* the Razor team (NTBugtraq, 19-May-00) <br>
<br>
* (MS00-029). This code causes cpu utilization <br>
<br>
* to go to 100%. <br>
<br>
* <br>
<br>
* Tested against: Win98; NT4/SP5,6; Win2K <br>
<br>
* <br>
<br>
* Written for: My Linux box. YMMV. Deal with it. <br>
<br>
<br>
* <br>
<br>
* Thanks: This is standard code. Ripped from lots of places. <br>
<br>
* Insert your name here if you think you wrote some of <br>
<br>
* it. It's a trivial exploit, so I won't take credit <br>
<br>
* for anything except putting this file together. <br>
<br>
*/ <br>
<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------ <br>
<br>
HOW DO FIREWALLS PROTECT AGAINST THIS ATTACK? <br>
<br>
------------------------------------------------------------------ <br>
<br>
<br>
(STATEFUL) PACKET FILTERING FIREWALLS: <br>
<br>
<br>
<br>
* The packet fails structural integrity tests. The reported <br>
<br>
length (68) is much larger than the received length (29). <br>
<br>
However: A broken router may decide to send 68 bytes when <br>
<br>
forwarding it (adding 39 bytes of random padding). <br>
<br>
I do not know what impact this will have on the receiving <br>
<br>
end. <br>
<br>
<br>
<br>
* This incarnation of the attack is also illegal in that it <br>
<br>
wraps the IP packet size limit. The IP data length reported <br>
<br>
<br>
is 48, and the offset is 65520. <br>
<br>
<br>
<br>
* If the firewall has any sort of (pseudo)fragment reassembly, <br>
<br>
it shouldn't forward a single packet, since there are <br>
<br>
no valid fragments preceding the attack sequence. <br>
<br>
<br>
<br>
* If the firewall maps fragments to open connections, it <br>
<br>
should detect that there is no open connection for this <br>
<br>
particular packet, thereby discarding it. <br>
<br>
<br>
<br>
PROXY FIREWALLS: <br>
<br>
<br>
<br>
<br>
* A proxy function will never pass this attack pattern to <br>
<br>
the protected network. (Note: assumes that there is no <br>
packet filtering functionality applied to the firewall) <br>
<br>
* If the proxy firewall is running on a vulnerable OS and <br>
doesn't have its own network layer code (relies on the MS stack), <br>
the attack will DoS the firewall itself, effectively <br>
DoSing your entire connection. <br>
<br>
ANY TYPE FIREWALL: <br>
<br>
* If the firewall does fragment reassembly in an incorrect <br>
way (maybe by trusting vulnerable MS stacks to do it), it <br>
will be vulnerable to the attack, regardless of which <br>
type of firewall it is. <br>
<br>
I will NOT speculate on which firewall is vulnerable to <br>
direct attack, protects against the attack, or passes <br>
it through. <br>
<br>
------------------------------------------------------------------ <br>
<br>
Well, that's it for this time. Again, please remember that this <br>
is an analysis of "jolt2.c" as provided to the security community. <br>
I have no intimate knowledge of the attack described by MS00-029 <br>
or Bindview, other than that publicly announced by them. <br>
<br>
The source of jolt2.c is attached. <br>
<br>
Regards, <br>
Mikael Olsson <br>
<br>
-- <br>
Mikael Olsson, EnterNet Sweden AB, Box 393, SE-891 28 諶NSK諰DSVIK <br>
Phone: +46-(0)660-29 92 00 Fax: +46-(0)660-122 50 <br>
Mobile: +46-(0)70-66 77 636 <br>
WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se <br>
~ <br>
<br>
-- <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="309.htm">上一层</a>][<a href="352.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -