Security Flaw with Linux 2.4 Kernel and IPTables

Sc00ter writes "According to this security advisory from Tempest Security Technologies there is a security flaw in the Linux 2.4 kernel when using IPTables." In a nutshell: if you're using a 2.4 system as a firewall, you need to read this.

Comments

Extent of the vulnerability

[rusty]

Hi all,

Summary: if you have multiple networks behind your iptables packet filter (eg. a DMZ) and you use the ip_conntrack_ftp module (or you compiled it into your kernel) you should apply the simple patch, otherwise a breakin on one protected network can be used to allow probes on the other protected network.

OK, so what happened? The connection tracking code in 2.4 (ip_conntrack) can be extended to understand complex protocols, like FTP (ip_conntrack_ftp). When it sees an FTP server or client say "for the data, connect to 1.2.3.4 port 56" it remembers it, and when that connection comes in, it classifies the packet as "RELATED", not "NEW" (as packets creating new connections are normally marked). Most packet filter setups simply allow all RELATED packets.

Of course, my original code only set up this "expectation" if the ftp server gave its own IP address in that "connect here" message. However, one early user, Enrico Scholtz, had a setup where the FTP server REALLY DID use a different IP address for the data connection. After some thought, I allowed it: you can allow arbitrary connections to be marked RELATED, but only from inside a network already.

The problem is that if you are using a single box to connect your DMZ, your internal network, and the outside world, and someone breaks into the DMZ, they can use a machine there (if you allow any FTP to or from those machines) to tell the firewall to expect a connection from the outside to the internal network, giving you access to probe your internal network.

The patch provided (by James Morris) in the posting simply stops returns to ignoring an FTP server or client which says to connect on a different IP from the one it is on. In some form, it will be in 2.4.4.

FYI, I was travelling while this broke, and the Netfilter Core Team handled the issue with great aplomb. Kudos to them!

Hope that clarifies,
Rusty.

Re:2.4 as a production firewall?

[signe]

As you said, if it ain't broke, don't fix it. And conversely, if it is broke, fix it as soon as possible.

I run a couple 2.4 production firewalls because we needed features available in IpTables that aren't available in IpChains, such as full NAT. There are reasons to run a bleeding edge firewall like a 2.4 system in production, you just have to balance the benefits with the cost of running something that is essentially beta.

In my case, the features outweigh the risk. I can deal with a little downtime, if neccessary, and I have other firewalls that give me rudimentary protection if my 2.4 box fails. Sure, it's not for you, and that's great. But it doesn't mean it's not for everyone.

-Todd
---

Rundown of the article

[marnanel]

The article's slow to load... so, as far as I can see, the problem is/was:

• Since FTP needs to open a separate connection for each data transfer, the firewall needs to track FTP commands that set up data connections, so it can make a specific hole in the firewall for that data to pass through.
• However, the firewall doesn't check with the FTP server that the hole is one that it knows about.
• You can therefore make the firewall allow any connection from any port on the FTP server to anywhere. (You don't even need to have an account on the FTP server, since the firewall will pick up the transfer commands whether or not you've previously logged in.)
• If you have an account on the FTP server as well, either by having already compromised it by other means, or by having an account on it anyway, then this hole in the firewall will be useful to you: it will be less useful if you're just a random outsider.

E feel free to correct me if I've got it wrong.

Not that recent

[Emphyrio]

As you can see in the relevant bugtraq post, this was made public about 4 days ago.
The fix is already in the archives (a check that ensures that 'RELATED' connection have the same source address as the initiating original connection), and works fine.

2.4 as a production firewall?

[Basalisk]

Anybody using a 2.4 kernel for a production firewall needs to be LARTed, for exactly this reason. Whenever a major architecture changes, many bugs are bound to appear. I will stick with a 2.2 kernel on my firewall until 2.4 has matured a bit more. For production systems, the latest and greatest can be bad, mostly because of those early bugs. It's best to stay about a year or so behind when it comes to major upgrades. I'll probably start using 2.4 on my servers late this year. Another factor is "If it ain't broke, don't fix it." Unless a kernel is seriously broken, I won't be upgrading. I upgraded my kernel recently because of security concerns, but I won't be jumping to a new branch until it has been somewhat stressed.