OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 4th quarter (Oct-Dec) 1996: Re: BoS: Urgent !! Serious Linux Security Bug....

Re: BoS: Urgent !! Serious Linux Security Bug....

David O'Brien (obrienNUXI.cs.ucdavis.edu)
Fri, 25 Oct 1996 01:14:05 -0700

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        (obriennuxi.cs.ucdavis.edu)