[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1D32004A-3106-4E79-8803-A5FFD01D6084@oracle.com>
Date: Wed, 30 May 2012 19:48:24 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request -- kernel: tcp: drop SYN+FIN messages
On 30 May 2012, at 19:25, Florian Weimer wrote:
> * John Haxby:
>
>> Recently we have a couple of queries relating to a Nessus "TCP/IP
>> SYN+FIN Packet Filtering Weakness". This has not been helped by the
>> fact that [1] actually points (indrectly) to CVE-2002-2438 which is
>> actually a SYN+RST problem.
>
> Reading the discussion here,
>
> <http://comments.gmane.org/gmane.linux.network/213981>
>
> it seems to me that this is just a performance optimization which
> could be bypassed by using different flags, so I don't think there's a
> vulnerability or fix here, except the general lack of source IP
> address validation in IP networks.
That's the same thread that I referred to but I didn't reach the same conclusion that you did. It is possible to block SYN+FIN in iptables, but the distros I'm aware of don't have that kind of check in place so people will be vulnerable to this kind of DoS.
The conclusion from the thread was that SYN+FIN is not a legitimate packet so the kernel should drop it. The nessus people seem to think the same thing: they have a test for this (although they refer to the SYN+RST fix from a decade ago). If there's a consensus that we don't need a CVE then we can go to nessus and have them fix, remove or update their test.
One could argue that if SYN+FIN doesn't need a CVE then SYN+RST didn't either since it can be blocked by the same, or very similar, iptables rule.
jch
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
