Re: Security Problems with Linux 2.2.x IP Masquerading (fwd)

[tony () CHELLO NL (Tony den Haan)]

---------- Forwarded message ----------
Date: Thu, 30 Mar 2000 14:52:36 -0300
From: Juanjo Ciarlante <jjo () mendoza gov ar>
To: Tony den Haan <tony () chello nl>
Cc: linux-kernel () vger rutgers edu
Subject: Re: Security Problems with Linux 2.2.x IP Masquerading (fwd)

On Tue, Mar 28, 2000 at 10:53:51PM +0200, Tony den Haan wrote:
> didn't see it here yet, so i decided to forward:
>
> [ Security Problems with Linux 2.2.x IP Masquerading ]
>
>
>
> Summary:
>
> Due to lax checking in the masquerading kernel code, an attacker is able
> to rewrite a linux masq gateway's UDP masquerading entries so that the
> remote host and port are whatever they choose. This creates a tunnel
> between whatever host and port they want and a UDP port on an inside
> machine.  The attacker is unable to tell what local inside ports and
> addresses are being used, but they can determine the number of currently
> masqueraded connections and the number of different hosts using those
> connections behind the firewall.  Any network where UDP traffic is
> masqueraded to the outside is vulnerable to this, including DNS, TFTP,
> NetBIOS, and a multitude of other applications which rely on UDP
> transport.  Since UDP is a connectionless protocol, the only way to
> determine that a masqueraded connection is no longer being used is by
> timing it out due to lack of activity or receiving ICMP messages
> indication the port is closed. The result is that there is a 5 minute
> time-out by default for all masqueraded UDP sessions, allowing an
> attacker enough time to find and exploit the connection with some of the
> methods outlined in the Examples section below.
>
> {nice example snipped}
Current UDP semantics were inserted sometime ago as a resource saving
hack:
  _map_ internal box UDP port _at_ masq box by being "destination
  loose" (DLOOSE) and thus:
       . saving from creating a new masq tunnel for each {src,dst} pair
       . allowing some applications that require comunicating with
         same (masq'd) UDP source addr:port.
The core problem is precisely not being able to actually _know_ when
internal box has closed the port.

You can easily revert to good"old" way (1 tunnel/pair) by commenting out
#define CONFIG_IP_MASQ_LOOSE_DEFAULT 1
at ip_masq.c:418 (stupid patch attached)

This should drop hijack'ing ... Could you try and tell us?

Of course, if we change the default, some way to enable it back
perhaps on a per-application basis (ip_masq module) MUST be done.

Regards

--
-- Juanjo       http://juanjox.kernelnotes.org/
            ... because there IS an OS that CAN follow your power


<HR NOSHADE>
<UL>
<LI>TEXT/PLAIN attachment: stored
</UL>