Re: TCP/BGP vulnerability - easier than you think
On 23-apr-04, at 8:35, Florian Weimer wrote:
So I believe filtering out all BGP RSTs on all edges is probably a good idea.
(Edges and borders.)
The problem is that even if you filter the RST, the state transition occurs at the side which receives the SYN and generates the RST. This means that the connection has been desynchronized and will eventually come down, no further data transfer is possible.
Although it doesn't follow from earlier text, on page 71 RFC 793 states that an in-window SYN should reset an ESTABLISHED session. So you are right. This is very bad. BTW, anyone seen anything supporting Paul Watson's claim that all it takes to break a session is four packets? I assume he's talking about this vulnerability that was fixed in FreeBSD in 1998: http://ciac.llnl.gov/ciac/bulletins/j-008.shtml I certainly hope our collective favorite vendors didn't overlook this one.
I point out NetBSD released this: ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc Of interest is this paragraph: ] 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. RSTs ] anywhere to the left of the window were treated as valid. It's a good thing the 4.4BSD stack was unpopular, otherwise it might be in a lot of programs. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Leo Bicknell wrote:
I point out NetBSD released this:
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
Of interest is this paragraph:
] 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. RSTs ] anywhere to the left of the window were treated as valid.
It's a good thing the 4.4BSD stack was unpopular, otherwise it might be in a lot of programs.
Most code bases fixed this much earlier, like FreeBSD in 1998; http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.80&r2=1.81&f=h Pete
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@duh.org> <tv@pobox.com>
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@duh.org> <tv@pobox.com>
_______________________________ Priscilla Oppenheimer www.priscilla.com When your Daemon is in charge, do not try to think consciously. Drift, wait, and obey. -- Kipling.
On 27-apr-04, at 5:03, Priscilla Oppenheimer wrote:
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.
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?
Looks that way to me.
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?
Yes. I think the idea is that if A has the session open and B has it closed, then the only real RSTs will be those that B sends for packets it receives from A. If those packets have and acknowledgement number in them (which should always be the case for established sessions) then this will be the RST's sequence number so there will be a perfect match between what A expects from an RST and what B sends. The situation where B legitimately sends a sequence number that isn't an exact match is hard to imagine, as the ACKs A sends depend on the sequence numbers B sent and if the session is dead at B's end presumably B isn't burning up too many sequence numbers. But if this happens for some reason and A sends a dataless ACK packet obviously B will respond with an RST so we're back to the situation where B is sending an RST with the sequence number that A expects.
I didn't have it quite right though because I said the host that sends the ACK could keep sending and then that would trigger a RST. But the ACK triggers an immediate RST from the host that sent the original RST. This time the RST has the right sequence number (derived from the ACK). Maybe I would have gotten more responses if I hadn't admitted this was for my students. :-) I wear many hats and do work as a network operator too (but for a small network). Cheers, Priscilla Oppenheimer At 09:14 AM 4/27/04, Iljitsch van Beijnum wrote:
On 27-apr-04, at 5:03, Priscilla Oppenheimer wrote:
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.
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?
Looks that way to me.
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?
Yes. I think the idea is that if A has the session open and B has it closed, then the only real RSTs will be those that B sends for packets it receives from A. If those packets have and acknowledgement number in them (which should always be the case for established sessions) then this will be the RST's sequence number so there will be a perfect match between what A expects from an RST and what B sends.
The situation where B legitimately sends a sequence number that isn't an exact match is hard to imagine, as the ACKs A sends depend on the sequence numbers B sent and if the session is dead at B's end presumably B isn't burning up too many sequence numbers. But if this happens for some reason and A sends a dataless ACK packet obviously B will respond with an RST so we're back to the situation where B is sending an RST with the sequence number that A expects.
_______________________________ Priscilla Oppenheimer www.priscilla.com When your Daemon is in charge, do not try to think consciously. Drift, wait, and obey. -- Kipling.
Priscilla,
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
Meta-response: look at the discussion over at the IETF, in the tcpm Working Group. There's a nice summary as well as some interesting discussion on possible issues with these fixes. Unfortunately, the tcpm mailing list archive seems to be accessible via FTP as large monthly mailbox files only, so I cannot point you to the relevant individual messages. The threads are called "new work item: TCP security issue" and "draft-ietf-tcpm-tcpsecure". (There's also a lot of process discussion in there, about the way this issue was initially handled by a closed group and then presented as a work item for the working group. This is interesting but only marginally helpful to understand the technical content of the changes.) Oh no, wait, there's another mail archive for tcpm (not listed on the "official" WG page (http://www.ietf.org/html.charters/tcpm-charter.html): The threads start in https://www1.ietf.org/mail-archive/working-groups/tcpm/current/msg00086.html https://www1.ietf.org/mail-archive/working-groups/tcpm/current/msg00095.html A nice summary of the changes by David Borman: https://www1.ietf.org/mail-archive/working-groups/tcpm/current/msg00130.html Hope this helps, -- Simon.
participants (6)
-
Iljitsch van Beijnum -
Leo Bicknell -
Petri Helenius -
Priscilla Oppenheimer -
Simon Leinen -
Todd Vierling