TCP/BGP vulnerability - easier than you think

Priscilla Oppenheimer po at priscilla.com
Tue Apr 27 03:03:06 UTC 2004


Questions arose while trying to explain proposed TCP fixes to my students. 
Can y'all help me with these?

We were going over the "Transmission Control Protocol security 
considerations draft-ietf-tcpm-tcpsecure-00.txt" document here when the 
questions arose:

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

The questions have to do with this from the document:

the following changes should be made to provide some
    protection against such an attack.
    A) If the RST bit is set and the sequence number is outside the
       expected window, silently drop the segment.
    B) If the RST bit is exactly the next expected sequence number, reset
       the connection.
    C) If the RST bit is set and the sequence number does not exactly
       match the next expected sequence value, yet is within the
       acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an
       acknowledgment.

This solution forms a challenge/response with any RST where the value
    does not exactly match the expected value and yet the RST is within
    the window.  In cases of a legitimate reset without the exact
    sequence number, the consequences of this new challenge/response will
    be that the peer requires an extra round trip time before the
    connection can be reset.


So, per item C, does the recipient of a RST with a sequence number that 
does not exactly match the next expected sequence value not reset the 
connection? It sends an ACK but keeps the connection open?

The ACK will go to the correct TCP partner, not the attacker presumably. So 
then that partner resets. But where does this leave the other partner (the 
recipient of the RST)? Is the assumption that this side may continue 
sending, which would cause the other side to RST (since it closed the 
session) and this RST would have the correct sequence number so the 
connection would get reset from both partners' points of view?

Regardless of hackers, we're trying to figure out how to legitimately RST 
despite possibly not having the exact right sequence value.

Thanks,

Priscilla Oppenheimer




At 09:48 PM 4/23/04, Todd Vierling wrote:

>On Fri, 23 Apr 2004, Leo Bicknell wrote:
>
>: I point out NetBSD released this:
>:
>: 
>ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
>
>Yes.  I made reference to this in the "Vendor TCP oops-es" thread where I
>explained the conveniently forgotten magnitude scale of the problem.
>
>I find it rather amusing that so many folks are talking about various
>paper-over methods as The Fix (and that it's somehow only a threat to BGP4),
>rather than discussing the real issue:  how to fix the underlying TCP
>*implementation* problems.  As designed, TCPv4 still provides reasonable
>threat avoidance for non-AH sessions -- even on a 10GE link.
>
>Fixing the vendor stacks and putting in proper random source port allocation
>would alleviate a lot more than just this problem.  Then, if desired,
>AH/MD5/whatever could stack on top of that for even more magnitude bits.
>
>: ] Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did
>: ] not even check that a RST's sequence number was inside the window.
>
>: It's a good thing the 4.4BSD stack was unpopular,
>
>Several embedded OS's used the Net/2 (post-4.3-Tahoe) stack for a while and
>may still be maintaining license-cleansed forks of it.  I haven't checked
>directly, but if the problem was in 4.4, it was probably also in 4.3.  I
>know I'd done some sort of RST attack against a SunOS4.0 box in the past
>(silly IRC games, of course; see my other post), and that was a 4.2BSD fork.
>
>But, this could have been sarcasm on your part.  If so, it went right over
>my head.  8-)
>
>--
>-- Todd Vierling <tv at duh.org> <tv at pobox.com>


_______________________________

Priscilla Oppenheimer
www.priscilla.com

When your Daemon is in charge, do not try to think consciously. Drift, 
wait, and obey. -- Kipling.




More information about the NANOG mailing list