[Dshield] Vulnerability Issues in TCP
cbrenton at chrisbrenton.org
Thu Apr 22 21:29:54 GMT 2004
On Thu, 2004-04-22 at 06:44, Pete Cap wrote:
> Someone please correct me if I'm wrong, but,
> notwithstanding the AP news stories about this
> "vulnerability," is this not a problem with the
> IMPLEMENTATION of TCP rather than a problem with the
> underlying protocol itself?
Yes and no, here's the deal:
The vulnerability revolves around that fact that a TCP reset is
considered valid when it fits within the TCP window size. In order
words, an attacker does not have to match the current sequence number
exactly. So long as they use a number that is valid within the current
window, the connection will be reset. This was not a big deal "in the
old days" when the average window size was 8K. Its more of an issue now
that the average Window size is 32K-64K as as an attacker now needs to
make fewer guesses to find a valid sequence number because the window
size is so much larger.
Now, there is another component to this, the attacker also needs to know
the source & destination IP addresses and port numbers for the session.
If they can sniff the wire, this info is trivial to enumerate. If they
are not along the flow of the session, they have to guess at these
values. Source and destination IP is trivial of they know who they are
attacking. Destination port is also trivial as most services listen on
their well known port. The tricky part is the source port.
Some OS's make it easier than others to guess what source port is being
used. For example Windows, NetBSD and others hand out source ports
sequentially. So if you know how long the system has been up and how
busy it is, you can ball part what ports to hit. That or sniffing some
other outbound session will tell you the range of source ports currently
Also, the type of TCP connection is going to determine how easy this is
as well. For example Telnet would be pretty trivial as the session tends
to stay active for a long time. HTTP would be harder because sessions
are created and torn down so quickly.
So why all the hoopla about Cisco, Juniper & BGP? Well, Cisco and
Juniper are two of the OS's that use predictable source ports. BGP tends
to open an initial session and transmit all data through that one
session till its shut down or rebooted. Also, the IP addresses of BGP
peers is pretty well known and documented so picking targets is easy.
Finally, trashing BGP means that an attacker could make a good portion
of the Internet unreachable. Combine all these points together and this
obviously makes the issue pretty serious.
BTW, while we are focusing on BGP, in reality any long term session
based TCP application can be vulnerable, depending on the source OS.
So some of the problem is TCP, some is the vendor implementation, and
some of it is specific to the application using TCP. Its the combination
of all these things that really makes it an issue.
More information about the list