absmiddle Ping 就死

[版主] 節錄自國外某 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 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. 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 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). 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 dependant Apple Mac MacOs Crash See the Mac page for details 7.x.x 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 Workplace 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! panic Linux 1.2.13 Reboot, Patch available!, although this one hasn't Hang, been tested. No effect 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 system 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 incident 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 OS Version 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 ?