Debian and recent TCP vulnerability

[Mlor Apac]

Hello

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. Let's imagine a server that has publicly accessible tcp service enabled (e.g. http).

https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4609
http://kbase.redhat.com/faq/docs/DOC-18730

Thanks

[Nick Boyce-3]

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 ?).

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@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Mestnik-4]

On Fri, Sep 11, 2009 at 9:11 AM, Nick Boyce<nick@...> 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@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>
>

--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Mlor Apac:

> 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. Let's imagine a server that has publicly accessible tcp service
> enabled (e.g. http).

The actual set of issues impacting Linux has not been publicly
disclosed yet.

It is generally believed that connlimit is a suitable defense against
attackers who do not control many IP addresses.  connlimit is
available on etch's 2.6.18 kernel and lenny's kernel, but not for the
etchnhalf kernel/iptables combination (due to bug #504989).


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...