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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:27 EST