[Snort-devel] New opportunity for IDS evasion in patches totcpprotocol vulnerability

Smith, Donald Donald.Smith at ...530...
Wed Apr 28 06:53:06 EDT 2004

There is a draft http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
that covers the changes to tcp to mitigate this issue.
That is what the vendors I am talking with are implementing.
Donald.Smith at ...530... GCIA
pgpFingerPrint:9CE4 227B B9B3 601F B500  D076 43F1 0767 AF00 EDCC
kill -9 6111.2 

> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net 
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of 
> Milani Paolo
> Sent: Wednesday, April 28, 2004 5:42 AM
> To: Michael.Richardson at ...2449...
> Cc: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] New opportunity for IDS evasion in 
> patches totcpprotocol vulnerability
> > No, BGP does not have fixed port numbers for both peers. Like all 
> > protocols, one end picks a "random" port.
> ok, i got this wrong. BGP has the most critical vulnerability 
> to this type of attack for other reasons.
> > BGP doesn't really need to have RST at all. A simple ACL restricting
> > TCP RSTs to port 179 would suffice.
> The same attack can be done with SYN packets instead 
> (according to cisco advisory at least), so restricting/rate 
> limiting reset packets is not a solution.
> > The TCP spec will not, I hope, be changed.
> > It isn't broken.
> > Checking the ACK sequence number in the RST will increase effort for
> > the attack from 2^18 to 2^36 or so. IPsec will get rid of it.
> Whether or not the spec is changed, and whichever method is 
> used in future tcp implementations to bypass this problem, it 
> will make tcp implementations more restrictive in which tcp 
> reset packets they accept. Which means that snort's stream 
> state tracking/reassembly will have to take this into 
> account, when deciding what to do with a reset packet, 
> otherwise it may find itself out of sync from the end system, 
> and therefore vulnerable to evasion.
> In fact, I hope that the spec is changed, rather than have 
> each tcp stack implementation solve the problem with it's own 
> ad-hoc fix. The issue will have to be fixed at the tcp level, 
> since it is a vulnerability in the protocol.
> ciao
> paolo milani
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> ====================================================================
> This message and its attachments are addressed solely to the 
> persons above and may contain confidential information. If 
> you have received the message in error, be informed that any 
> use of the content hereof is prohibited. Please return it 
> immediately to the sender and delete the message. Should you 
> have any questions, please contact us by replying to 
> MailAdmin at ...2137... Thank you 
> ====================================================================
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... 
> Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/s> nort-devel

More information about the Snort-devel mailing list