[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables w/2.4 kernels

On Thu, 19 Apr 2001, Robert Bartels wrote:

> I heard about this today. Has anyone had a chance to look at it
> and determine if its possible to compromise a host that is
> running proftpd server and using netfilters with iptables under the 2.4.3
> kernel?
> i.e. Firewall script running on same box as ftp server...

If I understood correctly what bug you are talking about, it is not a
remote exploit. This bug may be used to circumvent a firewall, and
therefore try to establish connections to hosts/ports that were intended
to be blocked by the firewall. The ability to establish a connection does
not imply compromising a host, though; it merely implies that somebody can
_try_ to compromise a host behind a firewall. A patch has been made
available already, and I already applied it. You need to apply the patch
to the kernel sources, make dep bzImage modules and install it. Since just
ip_conntrack_ftp was modified, if you had it compiled as a module you need
not reboot, just unload the old module, install the new one, load the new
one and off you go. I attach the patch (as I took it off the net) since it
is very small. 

Should this patch be applied to the "official" debian kernel source
package, perhaps?



Giacomo Mulas <gmulas@ca.astro.it, giacomo.mulas@tin.it>

Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel.: +39 070 71180 216     Fax : +39 070 71180 222

"When the storms are raging around you, stay right where you are"
                         (Freddy Mercury)
diff -urN linux-2.4.3.orig/net/ipv4/netfilter/ip_conntrack_ftp.c linux/net/ipv4/netfilter/ip_conntrack_ftp.c
--- linux-2.4.3.orig/net/ipv4/netfilter/ip_conntrack_ftp.c	Fri Aug 11 05:35:15 2000
+++ linux/net/ipv4/netfilter/ip_conntrack_ftp.c	Mon Apr 16 02:18:30 2001
@@ -187,7 +187,12 @@
 	       (int)matchlen, data + matchoff,
 	       matchlen, ntohl(tcph->seq) + matchoff);

-	/* Update the ftp info */
+	/*
+	 * Update the ftp info only if the source address matches the address specified
+	 * in the PORT or PASV command.  Closes hole where packets could be dangerously
+	 * marked as RELATED to bypass filtering rules. Thanks to Cristiano Lincoln
+	 * Mattos <lincoln@cesar.org.br> for the report.
+	 */
 	if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3])
 	    == ct->tuplehash[dir].tuple.src.ip) {
@@ -197,13 +202,8 @@
 		info->ftptype = dir;
 		info->port = array[4] << 8 | array[5];
 	} else {
-		/* Enrico Scholz's passive FTP to partially RNAT'd ftp
-		   server: it really wants us to connect to a
-		   different IP address.  Simply don't record it for
-		   NAT. */
-		DEBUGP("conntrack_ftp: NOT RECORDING: %u,%u,%u,%u != %u.%u.%u.%u\n",
-		       array[0], array[1], array[2], array[3],
-		       NIPQUAD(ct->tuplehash[dir].tuple.src.ip));
+		UNLOCK_BH(&ip_ftp_lock);
+		return NF_ACCEPT;

 	t = ((struct ip_conntrack_tuple)

Reply to: