-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 20, 2004, at 4:39 PM, Phillip Hofmeister wrote:
On Tue, 20 Apr 2004 at 02:49:48PM -0400, Thomas Sj?gren wrote:
Since the article is for subscribers only, this is a "wild" guess:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
This article isn't anything I am going to loose sleep over. Any
mission
critical long term TCP connections over an untrusted network (The
Internet) should already be using IPSec.
As for non-mission critical connections, the two parties will just
reconnect at a later time.
Also, unless the attackers know the source port of the client side of
the TCP connection, this attack is useless. The only way for them to
get the client/source port would be to:
A) Have access to the datastream (if this is the case, you have more to
worry about than them resetting your connection).
B) Have login access to either machine and then run netstat (or a
similar) utility which will tell them the information.
C) Guess.
I just ran netstat, and the first outgoing connection I made after
booting is using source port 1025. As it always does. Am I the only
one running programs from startup scripts? Probably not.
I also have to mention that I noticed this "vulnerability" about a year
ago (which was rather late, really). I wish I'd written up a warning
then and started all this fuss. I still haven't gotten around to
writing a test program.
I do have a few thoughts on countermeasures:
Use IPsec as previously mentioned.
Randomize your source port numbers. You can do this by calling bind
before you call connect. Maybe the kernel should choose source port
numbers at random on it's own, but that's a topic for the kernel
developers to discuss. At any rate, you can choose your source port
yourself. I'd be very interested to hear of any well-intentioned
programs that depend on the source ports being assigned sequentially.
Programs which rely on these persistent connections should be written
in such a way as to allow them to re-initiate a lost connection with
minimal work. I don't know anything about BGP, but this would be a
good maxim to apply to all programs that use a persistent connection, I
think. Perhaps the initiation phase should contain some indicator of
how much state each side has saved from the unexpected drop. I see
five possibilities: one side suffered a failure of some kind and has to
start from scratch (and the compliment), both sides suffered a failure
and have to start from scratch, the connection really is starting for
the first time, or some part of the network suffered a failure and both
sides should be able to pick up where they left off. The first four
cases would be handled just as new connections (in event of one or two
host failures it may also be necessary to clear the state on one or
both hosts beforehand). An ability to pick up as if the connection had
not been lost in the last case would help lower the amount of trouble
caused by network failures of this sort and also if a cable gets pulled
out for a few minutes et cetera.
Stop allowing packets with forged source addresses out of your network.
This means YOU! We probably can't get everyone do this, but the more
people who configure their networks right, the harder it will be for
attacks like this to be pulled off. I understand that it may not be
economically feasible to filter every packet on the Internet, but the
packet you block might just be the one that would bring down somebody's
TCP connection.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFAiBZBJNi06GN8d5gRAndMAJ0Q6ydwJYILT6ftQK4SK9wwQI7tIQCeJklC
47lm1nyZMKBRS3WLL3SqLX8=
=2xIH
-----END PGP SIGNATURE-----
