[14456] in bugtraq
Re: Security Problems with Linux 2.2.x IP Masquerading (fwd)
daemon@ATHENA.MIT.EDU (Tony den Haan)
Thu Mar 30 18:42:57 2000
Mime-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY=bg08WKrSYDhXBjb5
Content-Id: <Pine.LNX.4.21.0003302006530.6189@kleintje.nozone.nl>
Message-Id: <Pine.LNX.4.21.0003302006520.6189-200000@kleintje.nozone.nl>
Date: Thu, 30 Mar 2000 20:07:53 +0200
Reply-To: Tony den Haan <tony@CHELLO.NL>
From: Tony den Haan <tony@CHELLO.NL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--bg08WKrSYDhXBjb5
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0003302006531.6189@kleintje.nozone.nl>
---------- 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
--bg08WKrSYDhXBjb5
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.LNX.4.21.0003302006532.6189@kleintje.nozone.nl>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="ip_masq.c.noDLOOSE.diff"
--- net/ipv4/ip_masq.c.dloose Thu Mar 30 14:51:06 2000
+++ net/ipv4/ip_masq.c Thu Mar 30 14:57:24 2000
@@ -415,7 +415,7 @@
/*
* By default enable dest loose semantics
*/
-#define CONFIG_IP_MASQ_LOOSE_DEFAULT 1
+/* #define CONFIG_IP_MASQ_LOOSE_DEFAULT 1 */
/*
--bg08WKrSYDhXBjb5--
