Re: CVE Request -- kernel: tcp: drop SYN+FIN messages

[Kurt Seifried <kseifried () redhat com>]

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