[Snort-devel] New opportunity for IDS evasion in patches totcpprotocol vulnerability
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.
> paolo milani
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom
> Italia S.p.A.
> CONFIDENTIALITY NOTICE
> 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.
> 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