-----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.htmThis article isn't anything I am going to loose sleep over. Any missioncritical 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-----