[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
