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

[John Haxby <john.haxby () oracle com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

jch


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/IfvkACgkQRQu7fpQvo8h47wEAjQCY/RBRWng2hNe446T862+K
TczzjV2WpkBeQ3DE/5cBAIiBL0y4fdBkojnGTRyWuDuN4Tl8L+SH98aNWT0mPtXo
=hEGv
-----END PGP SIGNATURE-----