Re: Debian and recent TCP vulnerability
On Fri, Sep 11, 2009 at 9:11 AM, Nick Boyce<nick@glimmer.adsl24.co.uk> wrote:
> Mlor Apac wrote:
>
>> What's the status of debian (and linux kernel in general) regarding this
>> recent TCP vulnerability? I have been unable to find any precise
>> information.
>
> I too am wondering about this.
>
> The basic Linux stance is presumably that stated in the Redhat advisory
> you referenced :
> http://kbase.redhat.com/faq/docs/DOC-18730
>
> "Due to upstream's decision not to release
> updates, Red Hat do not plan to release updates
> to resolve these issues"
>
> Microsoft's bulletin
> http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx
> for the same problem-set is similarly half-hearted :
>
> "The architecture to properly support TCP/IP
> protection does not exist on Microsoft
> Windows 2000 systems, making it infeasible to
> build the fix ... To do so would require
> rearchitecting a very significant amount of
> ... Microsoft Windows 2000"
>
> "By default, Windows XP [does] not have a
> listening service configured in the
> client firewall and [is] therefore not affected
> by this vulnerability ... [what kind of
> answer is that !] ... a system would become
> unresponsive due to memory consumption ...
> the system will recover once the flood ceases
> .... Microsoft recommends [customers] use
> [a firewall] to block access to the
> affected ports."
>
> [duh]Using a firewall to block access to listening ports is no use at
> all as a solution for a system which runs services which must remain
> accessible.[/duh]
>
> I'm guessing the Linux kernel folks' stance is some combination of the
> above Microsoft statements, but haven't found any significant discussion
> of it yet. Redhat's recommendation is also to use firewalling to
> mitigate the problem (though admittedly 'iptables' features are better
> able to help than those of most firewalls [AFAIK]).
>
> I worried about this bit :
>
> "The following iptables example [ensures that]
> if 10 connection attempts to any TCP port are
> received within 5 minutes, they are dropped"
>
> Imagine how quickly that limit of 10 TCP connections in 5 minutes would
> be reached by a web browser talking to a web service - especially if the
> browser wasn't using HTTP 1.1 pipelining for some reason (proxy issues ?).
>
If I'm reading these rules correctly after a connection close (FIN)
the counter is removed, so the attack could still function IF the
attacker closed a bogus connection after every 7 or so attacking
connections. In my experiance it's vary difficult to discover if a
connection has closed, this check dosen't work if the user hits the
stop buttion and terminates the connection b4 the web server does...
It also dose not cover RST problems that close connections.
If you ask me this would be a good addition to the "conntrack" module,
a DONE(and perhaps FINISHED and TIMEDOUT) state. "recent" could also
use port numbers(but I guess that means bringing in TCP and UDP
goodness that's likely avoided), as a solution I suggest setting one
of these up for each service you expose.
For example, this should cause errors:
iptables -N service_a || true
iptables -F service_a; # I know it looks awkward, but try to think
that this code could be called more then once... and with "set -e".
iptables -A service_a -p tcp -m conntrack --ctstate
RELATED,ESTABLISHED -j ACCEPT
iptables -A service_a -p tcp -m conntrack --ctstate
DONE,FINISHED,HALFOPEN -m recent --name service_a_clients --remove
iptables -A service_a -p tcp -m recent --name service_a_clients --set
iptables -A service_a -p tcp -m recent --name service_a_clients
--update --seconds 300 --hitcount 10 -j DROP
iptables -p tcp --dport -j service_a
> Cheers
> Nick Boyce
> --
> But if we find we have left our bones to bleach in these desert
> sands for nothing, beware the fury of the legions...
> -- Centurion in a letter home from North Africa
> 3rd Century
>
>
> --
> To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
Reply to: