oss-sec mailing list archives
Re: CVE Request -- kernel: tcp: drop SYN+FIN messages
From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 01 Jun 2012 10:12:25 -0600
-----BEGIN PGP SIGNED MESSAGE----- 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 ConsiderationsAs 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 defectiveSee RFC 1644.RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional Specification" (July 1994): found defectiveThe 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 firewalls). 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPyOnpAAoJEBYNRVNeJnmTMSAP/R6u8VqLXdDM/vPnZVU6acyK lIi1GQH12O5F70qyIrpf0Sb+dmmGPH1Pl22WzIZ8j4FHiGFzBlsx3o+UnAUswzNA gk/gglkdafasNxVCh78aCbmoecQkzkRt6esqpJhdkDW8g8rB2maxVByOwDbezDPe kzDqEP6nnXguWLgizdbT+QYdDyUoX2x+V5Ga06+ZFpHYONWNItvvswdkWk1IoRaX kR+cdouG4iFzLv1R66tLs4oAlm636uax88hf5NPLWzIy0+3PO10ZJ+0GoDGFCow6 Q2CuOvrNqCgcY4PfD9CFQy8bqsL4u/wBCS8HksbaWaCOqp+fUBUVSg6lpG0a5iMn 2POys43UDB2ANqbmR/+hQ/IPhfYMRnQqkay50sBmnNk9MM1YkSH9Ue9Iz+CLqV9S CxNIcJrfiD1ZwF9DoD0rrXeVS4kHKVf8s4QdMNQCVOg85h91MpUJ7lN7CkTi0Ogy ZVKvYJUjU225WLUXHH74+Hk/Lc6OFODPBVdWbhn3m1s9d3s+b4GPVNtSVgsxt5Vm byOo6rB9I3CnN1kDIjRAcBGh/Cwdr28jbaEWxULVIgNXkLr7PofRGuP46ziZclzE TAt7CStxUoRqIZ8WxKErdNZIbBw/Y7BiNfZGUFvvIsKpHgXcRFpcgRAP8FZoWVhQ MpOPylIlpoqYUK3XifSk =rsNh -----END PGP SIGNATURE-----
Current thread:
- CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Florian Weimer (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (May 30)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (May 31)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (Jun 01)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (Jun 01)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (Jun 01)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (Jun 01)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (Jun 07)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (Jun 07)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages John Haxby (Jun 08)
- Re: CVE Request -- kernel: tcp: drop SYN+FIN messages Kurt Seifried (May 31)