Serious potential TCP-IP FLAW(was Re: kernel panics at google)

[Matt]

This is very frightening.

This bug seems to exploit a flaw in the tcp-ip protocol.
I have been informed of a potential security breech which was posted on
bugtrack yesterday. FreeBSD is buzzing about how big a deal this appears
to be. This message apparently has not made it here. This concerns me,
because it either means we are not keeping up, or we are not being
informed of what may be serious issues. Another note is that the message
below was sent to the FreeBSD guys, only to discover that at least some of
the snippets are from Linux Kernel code and can not be found in the
FreeBSD Kernel Code. For further info, the FreeBSD-security list has a
HUGE discussion going on about this. 

I hope that this is informative enough to allow the real coders(of which I
am only trying to be) somthing to work with.

---------- Forwarded message ----------
Date: Tue, 18 Jan 2000 14:44:38 -0800
From: The Tree of Life <ttol en JAMES.KALIFORNIA.COM>
To: BUGTRAQ en SECURITYFOCUS.COM
Subject: stream.c - new FreeBSD exploit?

I've been informed today by an irc admin that a new exploit is circulating
around.  It "sends tcp-established bitstream shit" and makes the "kernel
fuck up".

It's called stream.c.

The efnet ircadmin told me servers on Exodus (Exodus Communications) were
being
hit and they managed to get a hold of the guy.  When asked what was going
on, he just said "stream.c".

When I talked to another person to ask if he had 'acquired' the source, he
said he wasn't going to give it out.  I asked him if he had a patch for
it, and he replied "the fbsd team is working on it.  No patch is available
right now."

What's the importance of this?  Major companies such as Yahoo
(www.yahoo.com) and others run freebsd.

According to the irc admin, a simple reboot fixes it.  "Your box reboots
or dies."  He also stated, when asked if anything noticeable happened,
that "nothing unusual [happened]".

The only log that he could provide was this one:

---snip---

syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty

---snip---
One thing of note:  he also stated this happened on non-freebsd systems,
which is contrary to what the other person said, who was "under the
impression it was freebsd specific."

I have the source, which I'm not going to post for 2-3 days (give time for
fbsd to work on the fix).  If it isn't out before the 21st, I'll post it
up.

---snip---

void usage(char *progname)
{
   fprintf(stderr, "Usage: %s <dstaddr> <dstport> <pktsize> <pps>\n",
progname);
   fprintf(stderr, "    dstaddr  - the target we are trying to
attack.\n");
   fprintf(stderr, "    dstport  - the port of the target, 0 =
random.\n");
   fprintf(stderr, "    pktsize  - the extra size to use.  0 = normal
syn.\n");
   exit(1);
}
---snip---

Thanks for listening to my ramblings, hope everything I said helps.

- ttol
http://www.alladvantage.com/home.asp?refid=AME389
Get Paid to Surf.  It works actually, cause people get thousands of
dollars a month from it...it's neet :P  My id is AME389 - use it! :)

Matt Berglund
Junior System Admin/Water Boy at Reality Check Information Inc.
mberglund en realestatesafari.com

Starting Java ... Killing Netscape.


On Thu, 20 Jan 2000, Alan Cox wrote:

> > If I'm interpreting the kernel oops correctly, the error occurs in
> > tcp_retrans_try_collapse.  I've attached below the oops, after
> > attempting to run it through ksymoops.  (I think I got the right
> > symbols, but I'm not absolutely certain.)
> 
> It seems to , although the error appears to have occurred at some point
> before that, and tcp_retrans_try_collapse gets handed a buffer which appears
> to either have been freed, or not to be on a list (skb->next == NULL).
> 
> 
> > We could really use informed suggestions about what could be triggering
> > this, or how we might try to work around it.  Thanks very much in
> > advance for any help.
> 
> Workaround suggestion: echo "0" >/proc/sys/net/ipv4/tcp_retrans_collapse
> 
> > >>EIP: c0158892 <tcp_retrans_try_collapse+3a/208>
> > Trace: c01462cb <__kfree_skb+97/a0>
> > Trace: c0158be7 <tcp_retransmit_skb+a3/164>
> > Trace: c0158d0d <tcp_xmit_retransmit_queue+65/e4>
> 
> This seems to to be the interesting area and looks suspicious:
> 
> Dave: Side item tcp_retrans_try_collapse doesnt seem to care about collapsing
> in SACK'd data - is that right ?  
> 
> Second question:  tcp_xmit_retransmit_queue is entered with tcp->retrans_head
> pointing part way into the retransmit queue if we baled part way through
> the previous retransmit run (eg cos cwnd got us). We guarantees that
> tp->retrans_head is still pointing to a valid packet so right now I
> cant see a cause.
> 
> Do all the crashes basically look identical ?
> 
> Alan
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo en vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/