Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 01 Jun 2012 10:12:25 -0600
From: Kurt Seifried <>
To: John Haxby <>
Subject: Re: CVE Request -- kernel: tcp: drop SYN+FIN messages

Hash: SHA1

On 06/01/2012 02:36 AM, John Haxby wrote:
> On 31/05/12 18:44, Kurt Seifried wrote:
>> To clarify: CVE-2012-2663 is for the --syn processing flaw of
>> SYN+FIN packets in iptables (user space tools). c Also if people
>> could test their firewalls to make sure this still doesn't affect
>> other operating systems that would probably be a good idea.
> It's not clear to me why you would want to allow SYN+FIN at all.
> So far as I have been able to discover t is only used for T/TCP
> which was obsoleted in May 2011 by RFC6247 which said this:
>> 4. Security Considerations
>> As mentioned in [RFC4614], the TCP Extensions for Transactions 
>> (T/TCP) [RFC1379][RFC1644] are reported to have security issues 
>> [DEVIVO].
> RFC4614 has this to say:
>> RFC 1379 I "Extending TCP for Transactions -- Concepts"
>> (November 1992): found defective
>> See RFC 1644.
>> RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional 
>> Specification" (July 1994): found defective
>> The inventors of TCP believed that cached connection state could 
>> have been used to eliminate TCP's 3-way handshake, to support 
>> two-packet request/response exchanges. RFCs 1379 [RFC1379] and 
>> 1644 [RFC1644] show that this is far from simple. Furthermore, 
>> T/TCP floundered on the ease of denial-of-service attacks that
>> can result. One idea pioneered by T/TCP lives on in RFC 2140, in
>> the sharing of state across connections.
> I'm not averse to this being an iptables problem, I just wondered
> why that is the case given the reasons for making T/TCP historic.

Like I said we might assign a CVE for the kernel as well. As was
pointed out to me this is two issues:

1) iptables doing something unexpected, but sort of technically
quasi-correct (the best kind of correct ;), realistically firewalling
of packets should also include firewalling of modified/mangled version
of the packets (because that's what attackers do to circumvent

2) OS level, should we allow SYN+FIN at all? Is this a responsibility
for the operating system? To some degree yes, it should probably not
create a connection based on a mangled SYN packet (and this has been
fixed in the 3.x series). Is this a security issue or a security
hardening, debatable, but in any event it's a separate code base
(kernel) so it would get a separate CVE from the iptables side.

> jch

- -- 
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.