Date: Fri, 01 Jun 2012 10:12:25 -0600 From: Kurt Seifried <kseifried@...hat.com> To: John Haxby <john.haxby@...cle.com> CC: oss-security@...ts.openwall.com Subject: Re: CVE Request -- kernel: tcp: drop SYN+FIN messages -----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 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 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-----
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.