[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 08 Jun 2012 09:35:13 +0100
From: John Haxby <john.haxby@...cle.com>
To: Kurt Seifried <kseifried@...hat.com>
CC: oss-security@...ts.openwall.com
Subject: Re: CVE Request -- kernel: tcp: drop SYN+FIN messages
On 07/06/12 19:37, Kurt Seifried wrote:
> On 06/07/2012 01:31 AM, John Haxby wrote:
>
> > On 01/06/12 20:12, Kurt Seifried wrote:
> >> In my limited testing with iptables on RHEL 6.2 it appears that
> >> --state NEW works properly, and won't allow SYN+FIN to create
> >> connections (I used hping3 and the SYN+FIN Packets were
> >> blocked).
>
> >> So the default ruleset:
>
> >> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT
> >> -m state --state NEW -m tcp -p tcp --dport 22 -j DROP -A INPUT -j
> >> REJECT --reject-with icmp-host-prohibited
>
> >> should work, so you could do you clever --syn bits first and then
> >> have that set to protect stuff from SYN+FIN.
>
> > What happens if you have "-j ACCEPT" instead of "-j DROP"? I
> > would expect that sshd wouldn't see the connection but you would
> > get all the unpleasant side effects that made T/TCP deprecated.
>
> Ooops yeah typo, that DROP should have been ACCEPT. So to summarize
> properly:
>
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
>
> results in ICMP unreachable (the -F -S bypasses the "--dport 22 -j
> ACCEPT" but gets caught in the final "icmp-host-prohibited" rule) with:
>
> hping3 -c 3 -n -S -F -p 22 192.168.51.195
>
> with:
>
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j DROP
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
>
> with hping -F -S the packets bypass the "--dport 22 -j DROP" and get
> caught by the icmp-host-prohibited
>
> with hping -S the packets get caught by "the "--dport 22 -j DROP"" as
> expected.
>
> So basically --state new works fine and dandy.
>
>
> > jch
>
>
Good. That makes the kernel change just hardening then. If you're
not using iptables you're leaving yourself open to all kinds of abuse
anyway so I don't think we need a CVE for the kernel.
jch
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.
