[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re[2]: BoS: Urgent !! Serious Linux Security Bug....
From:       Mike Bremford <Mike.Bremford () mail ! bl ! uk>
Date:       1996-10-25 18:01:52
[Download RAW message or body]

     I've gotten a helluva lot of mail on this since I started up my web
     page on the topic. The summaries are presented there, but if you are
     really curious or want details I can forward on specific messages to
     you. It's at http://www.sophist.demon.co.uk/ping, but it *is* only
     covering the results of a ping, not the internals. (I'm thinking more
     from a "how-can-I-stop-it" point of view than a
     "why-does-it-happen"...)

     Cheers... Mike


______________________________ Reply Separator _________________________________
Subject: Re: BoS: Urgent !! Serious Linux Security Bug....
Author:  "David O'Brien" <obrien@NUXI.cs.ucdavis.edu> at Internet
Date:    25/10/96 01:14


Tom Guptill writes:
> I just wanted to note that some of the diagnoses people are using to track
> this problem might be a bit shaky.  For example, if you're not doing your
> diagnosis on the console or on a serial terminal, the machine might appear
> to be "hung" during the test when in fact you've simply blocked it from
> receiving network traffic.  (Not that this isn't a problem, mind you.)

I would also like to start a discussion on just what the vulnerability is
vs. what systems are vulnerable.

This may be quite well known (and some of it is inferred from previous
messages), but I'd like to double check with people that may have
definitive answers.  Using snoop on Solaris 2.5, I watched a ``ping -l
65510'' from an NT 4.0 box.  At first I thought maybe Microsoft was
sending IP or ICMP packets with bad options, or field values.  But, it
appears there is nothing malformed with the packets other than they are
too long (per RFC 791 - INTERNET PROTOCOL SPECIFICATION).  ``ping -l
65510'' ==> ICMP datagram of 8 (ICMP hdr) + 65510 (data) = 65518 octets.
Add to this the minium IP hdr of 20 octets and get we 65538 octets.  This
is 2 octets > maximum allowed IP datagram of 65536.

The real problem appears to be that when a [vulnerable] host gets this
huge ping datagram, it has to create a simular ping datagram to return to
the sender.  The return datagram must return the incoming ping datagram's
data section as its own.

So when the [vulnerable] host is assembling this huge datagram it does
something like

        ``memcpy( assemble_buffer+20+8, ping_pkt->data, ping_pkt->data_len )''

over running the assemble_buffer which is a fixed value of 65536.  On the
systems that instantaneously reboot, we are just "fortunate" enough to
have stomped on some important kernel data structure.

Opinions?  Confirmations?  Specific kernel code snippets with explanations
(for those that don't hack that particular system's kernel)?

--
-- David        (obrien@nuxi.cs.ucdavis.edu)

[prev in list] [next in list] [prev in thread] [next in thread]