Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 May 2012 14:07:21 -0600
From: Kurt Seifried <>
CC: John Haxby <>
Subject: Re: CVE Request -- kernel: tcp: drop SYN+FIN messages

Hash: SHA1

On 05/30/2012 12:48 PM, John Haxby wrote:
> 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,
>> <>
>> 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

No this definitely gets a CVE (see previous email), it directly
bypasses a security mechanism that is documented (man iptables, --syn
section), and other parts of iptables do handle it correctly as far as
I can tell (e.g. --state NEW). It allows bypass of firewall rules as
documented, so if that doesn't get a CVE then nothing the world has
gone upside down =).

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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.