[版主] 節錄自國外某 Homepage, 只把跟 PC OS 較相關的留下來.
The Ping o' Death Page
How to crash your operating system!
Maintained by Mike Bremford, last updated 06-12-96, 0030 GMT
Please mail me with any updates, corrections or new information, being sure
to include the word "ping" in the subject line.
OK, rumour has it some people want to see what's been updated rather than
rechecking the whole list each time. Fair enough. My daily diary of whats
latest and greatest can be found here.
1. The Problem
In a nutshell, it is possible to crash, reboot or otherwise kill a large
number of systems by sending a ping of a certain size from a remote machine.
This is a serious problem, mainly because this can be reproduced very
easily, and from a remote machine. (During tests, my machine in London,
England has been crashed from a machine in Berkely, California), and because
the attacker needs to know nothing about the machine other than its IP
address. Be afraid. Since I started this page on the 21st October, over 18
major operating systems have been found vulnerable.
It's very easy to exploit - basically, some systems don't like being pinged
with a packet greater than 65536 bytes (as opposed to the default 64 bytes).
This bug is not limited to Unix, but is popping up on Macs, Netware,
Printers, Routers...the list goes on. Patches are coming out extremely fast
- the award did go to the Linux community for getting a patch out within
three hours (well, 2 hours 35 minutes 10 seconds if you must know), but Bill
Webb from Telebit assures me that the Netblazer patch was out within two! OK,
OK, you can share the prize money... :-)
An IP datagram of 65536 bytes is illegal, but possible to create owing to
the way the packet is fragmented (broken into chunks for transmission). When
the fragments are reassembled at the other end into a complete packet, it
overflows the buffer on some systems, causing (variously) a reboot, panic,
hang, and sometimes even having no effect at all...
Most implementations of ping won't allow an invalid datagram like this to be
sent. Among the exceptions are Windows '95 and NT, although they are
certainly not the only ones...
1.1 A far better explanation of the problem
Thanks to Paul Gortmaker we now have a decent explanation of why this is
Background Information on ICMP ECHO ("ping"):
IP packets as per RFC-791 can be up to 65,535 (2^16-1) octets long, which
includes the header length (typically 20 octets if no IP options are
specified). Packets that are bigger than the maximum size the underlyling
layer can handle (the MTU) are fragmented into smaller packets, which are
then reassembled by the receiver. For ethernet style devices, the MTU is
An ICMP ECHO request "lives" inside the IP packet, consisting of eight
octets of ICMP header information (RFC-792) followed by the number of data
octets in the "ping" request. Hence the maximum allowable size of the data
area is 65535 - 20 - 8 = 65507 octets.
What causes my machine to crash from this?
Note that it is possible to send an illegal echo packet with more than 65507
octets of data due to the way the fragmentation is performed. The
fragmentation relies on an offset value in each fragment to determine where
the individual fragment goes upon reassembly. Thus on the last fragment, it
is possible to combine a valid offset with a suitable fragment size such
that (offset + size) > 65535. Since typical machines don't process the
packet until they have all fragments and have tried to reassemble it, there
is the possibility for overflow of 16 bit internal variables, which can lead
to system crashes, reboots, kernel dumps and the like.
1.2 Another twist...
With all this talk of ping, it's easy to miss the root of the problem. Joel
Maslak has pointed out that this exploit is by no means restricted to ping.
The problem can be exploited by anything that sends an IP datagram -
probably the most fundamental building block of the net. Not only ICMP echo,
but TCP, UDP and (apparently) even new style IPX can be used to hit machines
where it hurts.
Bottom line is that blocking ping at the firewall is a temporary fix only.
The only solution is to secure the kernel against overflow when
reconstructing IP fragments. (To the best of my knowledge, all of the
patches currently available fix the problem). So don't think you're safe
just because you've blocked ping. Damage could be done through NFS, telnet,
http... in short, any port your machine listens on is a target (and maybe
even those you don't listen on... anyone?)
2. How to test if you're vulnerable
Unfortunately, this bug is really easy to exploit. Users are already trying
it out "just to see if it worked". So, to test if your machine is in danger,
find a Windows '95 or NT box (3.51 or 4), and run the following command:
ping -l 65510 your.host.ip.address
The message on the '95 box will be "Request Timed Out". This means that the
ping wasn't answered, either because the machine is ignoring you (and
rightly so if you're going to send it invalid packets), or because it's dead
It's that simple...
Now, courtesy Bill Fenner, those of us without access to '95 or NT can crash
machines too - go here for the source code to an evil implementation of ping
Apparently, according to Volker Ossenkopf, the ping command on Linux can be
rebuilt with a higher package size limit in the ping source, and used to
whack machines too. Remember, Linux Ping must be run as root. Note - I've
tried this and can't make it work... Volker did it with Kernel 1.3.84, so
maybe things have changed since then I've also been given a pointer by
Darren Reed to this package, which is "a generic tool for testing the
robustness of IP stacks. It includes tests which try to exploit many
different problems." It sounds like it would probably identify this ping
problem, plus any others lurking in your networking code. If you're having
trouble reproducing this, try loading the machine up. Although it's hard to
tell, it seems that a nearly idle machine is more likely to withstand the
"Ping O'Death" than one which is busy/swapping/otherwise earning it's living
This is possibly due to a memory overflow being more likely to hit something
important if the machine is busy... also, I've been told the maximum size
packet from Windows'95 is 65527, which is 20 bytes over the legal limit.
This may produce more spectacular results than a 65510 ping. Unfortunately,
while Irix 6.2 has been patched to keep the 64k ping crash from occuring on
its servers, it now has the ability to send such a ping, even as a flood...
apparently this was some kind of retribution from the programmers so that
owners of Irix 5.3 could kill the people that killed them
3. How to prevent people from breaking your system
If no patch is available, and your main concern are pings from users outside
your network, it would seem the best quick-fix solution is to block ping at
the firewall. This is not a long-term solution. If you have *any* services
listening on any ports at all, they are vulnerable. Be assured that sooner
or later someone will come out with a program which sends invalid packets to
a web server, an ftp port. The only solution is to patch your operating
By blocking ping, you prevent people from pinging you at all. This could
possibly break some things that rely on ping - I believe that DEC
ObjectBroker uses ping to confirm a connection is still up. Other packages
may go too.
A better solution than blocking all pings is to block only fragmented pings.
This will allow your common-or-garden 64 byte ping through on almost all
systems, while blocking any bigger than the MTU size of your link. (This
varies, but about 1k is a good bet).
4. The affected systems
This is very much a work in progress. Please, any additional information you
come by mail me so I can update this page. Please include the word "ping" in
the subject line
4.1. Vulnerable operating systems without patches
This includes systems which I haved mixed reports on
OS Version Symptoms Comments
Solaris (x86) 2.4 Reboot No fix yet, although Sun have no reproduced
this and are working on a fix. (The bug ID,
if you want to.. er.. bug Sun about it, is
BUGID# 1226653 (changed!). Patches are now
available for 2.5 and 2.5.1, so expect 2.4
Real Soon Now (tm)
NEXTSTEP various Platform The vulnerability is to a 32768 byte packet
Apple Mac MacOs Crash See the Mac page for details
Windows 3.11 ? Mixed ne person has had no problems, another two
Trumpet Winsock reports get Onetwork errors and lose the network
connection - the machine had to be rebooted
to restore it
MSDOS with Lan ? Crash No fix yet
Novell Netware 3.x Mixed Ranging from crash to no effect. 3.11 with
results TCPIP.NLM v1.01 hangs the IP stack (IPX/SPX
stack is OK), while 3.12 with TCPIP.NLM 2.02
rev 9 is unaffected.
Windows NT 4.0 Crash Well, some may accuse me of scaremongering,
but I've been mailed a lovely little batch
file by Mark Rejhon that I have been told
will crash NT4 fairly reliably. Marks just
sent me a new script with better
"documentation",and has informed me that the
problem appears to be with sending the pings
- as is the case with NT 3.51, NT 4.0 seems
to be happier on the receiving end of the
ping of death. Either way, its a bug, but
unless your machine turns suicidal NT owners
have less to worry about (it would seem).
Windows '95 All of 'em Crash Once again, the same problem as NT 3.51 and
NT 4.0. '95 can be killed quite effectively
by sending a large ping (not receiving). Try
the instructions Microsoft have given for NT
3.51, and remember, your mileage may vary -
a lot of people have no problems
4.2. Vulnerable operating systems with patches
OS Version Symptoms Comments
Linux <=2.0.23 reboot, Patch available! Kernel 2.0.24 is out, which
kernel fixes this. Upgrade now!
Linux 1.2.13 Reboot, Patch available!, although this one hasn't
Hang, been tested.
Windows NT 3.5.1 Mixed The latest word is MS have acknowledged
results the problem and have released a patch (it
seems that sending a bad ping can make NT do
some funny things!). Some info just in is
that if you do as M*soft says (ping -l 65510
-s 1 ip.address) you can crash NT 3.51. So
maybe it is vulnerable after all.
Solaris (x86) 2.5 Reboot Temporary Patch availableSun has just come
2.5.1 out with these. Final versions should be
along any day. (I have no word yet on 2.4).
The Patch ID's are T103170-10 for 2.5 and
T103631-05 for 2.5.1
4.3. Operating systems which just possibly could be vulnerable
This is for systems where only one or two people have had trouble Operating
OS Version Symptoms Comments
NetBSD x86, 1.1 Mixed One person has managed to crash this, another
VAX 1.1a reports two have not, and another has not only failed
to reproduce this, but has checked the
source code and is certain it can't be done!
It sounds like the crash was an isolated
Apple ? Crash I am unsure of this. I've been told that ANS
Network is based on AIX 4.1.4, hich is vulnerable.
Server The AIX patches w will stop your machine
booting, so don't apply them! There's still
no word from Apple on this.
4.4. Safe operating systems
Solaris (Sparc) 2.3, 2.4, 2.5, 2.5.1
Windows 3.11 with Novell Client-32 / Cisco TCP/IP / ?
MultiNet / WRQ / NCSA / Pathway / MS TCP-32 stack
Windows '95 ?
OS/2 2.11, 3, 4
Novell Netware 4.1
MS-DOS w/ Clarkson Telnet ?