Sorry, in the case of BGP this would mean CERT is assuming that every ISP is ignoring the well known issue about vulnerability of Cisco routers and perhaps others. After that very urgent mailing about half a year ago I've edited as other ISP's especially all BGP relevant filters in such a manner that only the necessary p2p connections will be allowed. Compared to solve other vulnerability problems a very easy job!
For the remaining rest I agree to Phillip that its possible to sleep well in near future. ;) The problem is mainly essential to well known connections. But I think its a kind of playing roulette to hit a 16 bit window within a 32 bit sequential number! Now please don't misunderstand me - I think it's a problem which has to be worked on! I think a kind of three way handshaking or "RST cookie" could be a solution. Than it's only a small problem of compatibility for that the missing ability of reset could often be solved by timeouts or keepalive protocols. Christian -----Original Message----- From: Jones, Steven [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 11:15 PM To: debian-security@lists.debian.org Subject: RE: Major TCP Vulnerability CERT has issued a vulnerability email. They seem to think it's a little more serious.... 8><---- Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP 8><---- Your info may run over a IPSEC link but if the border routers of your ISP go down, your still stuffed. regards Thing -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Hofmeister Sent: Wednesday, 21 April 2004 8:42 a.m. To: debian-security@lists.debian.org Subject: Re: Major TCP Vulnerability 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. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import ----- End forwarded message ----- -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
