Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Flaw with Linux 2.4 Kernel and IPTables

Posted by michael on from the real-men-run-2.2.18 dept.

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.

13 of 74 comments (clear)

  1. Extent of the vulnerability by rusty · · Score: 5

    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.

  2. Mirror links by Erik+Hensema · · Score: 3

    Since the site is slashdotted, here are the links to the advisories on the netfilter sites:



    --

    This is your sig. There are thousands more, but this one is yours.

  3. Re:ftp by jmauro · · Score: 3

    It really only affect Active FTP sessions. Passive sessions really work without a problem with firewalls, because the connections and transfers are all done in band. If you want to save your self the trouble, just set all your FTP servers to passive only. No problem then at all.

  4. Re:2.4 as a production firewall? by signe · · Score: 5

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

    --
    "The details of my life are quite inconsequential..."
  5. Not as big as it might have been by wowbagger · · Score: 3
    This is not as big a hole as it might have been.

    The only way to exploit this is if the FTP client is under the attacker's control, and passing through the firewall. This breaks down into two possible catagories:

    1. The firewall is protecting an FTP server. In this case the attacker can connect to the server and punch holes in the firewall.
    2. The attacker is on the inside of the firewall, and has FTP access out.


    Case 1 is the most scare from a sysad standpoint: if I had set up a world-accessible FTP server protected by a Linux firewall, the world could punch holes in my firewall.

    Case 2 would be more the case of a company that chose to limit employees' access to the Internet, and the employees could use this to punch holes in the firewall. This is not as much a security risk (if you have employees who are security risks, you need to identify them and fire them.) After all, if one of your employees controls a server outside the firewall, he can always set up a proxy server on port 80 and do whatever he wants.

    Still, I'm glad this sort of thing was caught and corrected. This is why peer review is important for security....
    --
    www.eFax.com are spammers
  6. Re:ftp by Speare · · Score: 3

    It really only affect Active FTP sessions. Passive sessions really work without a problem with firewalls, because the connections and transfers are all done in band. If you want to save your self the trouble, just set all your FTP servers to passive only. No problem then at all.

    Um, that's not how passive mode ftp works. You still have two sockets for the FTP, whether active or passive. What changes is who will initiate the connection for the data.

    Without recently developed stateful firewall monitors, FTP is very difficult to arrange from host A behind firewall f(A) to host B behind firewall f(B). Active mode butts up against f(A), and passive mode butts up against f(B).

    FTP is a broken protocol.

    --
    [ .sig file not found ]
  7. Rundown of the article by marnanel · · Score: 5

    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.

    --
    GROGGS: alive and well and living in
  8. Not that recent by Emphyrio · · Score: 5

    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.

  9. Oh well... by jargoone · · Score: 3

    Looks like it's time to go back to ZoneAlarm.

  10. slash . 'ed by leuk_he · · Score: 4

    (since the site seems almost slashdotted a copy is made below)
    Security flaw in Linux 2.4 IPTables using FTP PORT

    Tempest Security Technologies
    a business unit of CESAR - Centro de Estudos e Sistemas Avançados do Recife

    Author: Cristiano Lincoln Mattos, CISSP, SSCP
    Recife, Pernambuco, Brazil

    Table of Contents

    Overview
    Detailed description
    Solutions
    Demonstration tool
    Download
    Acknowledgements
    Text version
    Overview

    Systems affected: Firewalls using Linux Kernel 2.4.x with IPTables

    Release date: 16 April 2001

    Platforms: Linux Kernel 2.4.x

    Impact: If an attacker can establish an FTP connection passing through a Linux 2.4.x IPTables firewall with the state options allowing "related" connections (almost 100% do), he can insert entries into the firewall's RELATED ruleset table allowing the FTP Server to connect to any host and port protected by the firewalls rules, including the firewall itself.

    Linux 2.4.x includes NetFilter, a raw framework for filtering and mangling packets. IPTables, used for firewalling, is set inside the NetFilter framework. One of the new features in this setting is connection tracking, known to some as "stateful inspection". The four possible states it can mantain are: ESTABLISHED, NEW, RELATED and INVALID. We are interested here in the RELATED state -- it includes, among other things, the FTP DATA connections, active (PORT command) and passive (PASV command).

    The module ip_conntrack_ftp is responsible for analysing FTP connections that pass through the firewall, looking for PORT and PASV commands, and including entries for those connections in the firewall's connection table. There is a security flaw in the manner in which the PORT command is interpreted and processed. Essentially, you can pass any IP/port in an FTP PORT commmand, and the module will not validate these parameters, adding an entry to the RELATED ruleset allowing connections from the FTP server, any source port, to the specified destination IP and port. In most cases, people make stringent security rules and have lax firewall rules regarding RELATED connections, allowing the attacker to connect to anywhere.

    This can be used, for example, for the FTP server to connect to any TCP port on the firewall, or any other node protected by the firewall. Even though there may be rules normally denying this type of traffic, it would pass through the firewall, because of the rule allowing RELATED.
    The attacker does not even need to have a valid login in the FTP server, as the PORT command is interpreted by the module independently of any authentication procedures (USER and PASS).

    This is a security flaw which can be exploited when an attacker is in a position behind your firewall, i.e., "protected". For example, if your firewall protects an FTP Server and the attacker has compromised it by other means, he can use this to connect to other protected networks. Or, if your attacker is behind your firewall as a client and connects to an FTP server on the Internet, he can use it to allow this FTP server to connect to other protected networks.

    Detailed description

    Most firewall setups using IPTables include the following rule, for allowing established and related connections through:

    iptables -A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT

    The "related" state includes connections such as the FTP data transfer connections, both active and passive modes. If related connections and FTP are allowed through the firewall, then the system is most likely vulnerable.

    The attack consists in connecting to the FTP server (passing through the firewall) and using the PORT commands with arbitrary IP and port parameters - the normal parameters should be the client's IP and a random port.

    To explain the process in more details, we'll outline the following scenario:

    Client IP: 200.249.243.12, an IP on the internet
    Firewall: 200.249.137.1 (internet interface) 200.249.193.1 (DMZ interface)
    FTP server: 200.249.193.2 (inside a DMZ network, protected by the firewall)

    In a normal ftp data transfer, the client would emit the following command to initiate an active data transfer:

    PORT 200,249,243,12,4,10

    Which would insert an entry in the connection table (cat /proc/net/ip_conntrack), of the following form:

    EXPECTING: proto=6 src=200.249.193.2 dst=200.249.243.12 sport=0 dport=1034

    Allowing a connection from the FTP server to the client in the specified
    port. Since the module ip_conntrack_ftp doesn't check the passed IP and
    ports, an attacker can pass the following parameters:

    PORT 200,249,193,1,0,22

    Which would insert an entry in the connection table (cat /proc/net/ip_conntrack), of the following form:

    EXPECTING: proto=6 src=200.249.193.2 dst=200.249.193.1 sport=0 dport=22

    Allowing a connection from the FTP server to the firewall, on port 22, ie, the SSH port. This will work by inserting the rule into the RELATED ruleset, which as shown above is normally too open. The rule can be inserted to any destination IP and port.

    Of course, the FTP server will probably not accept the command (if it has anti-bounce protection), saying "Illegal PORT command", but the firewall will have interpreted the commands and added an "expecting related" entry as described above to its connection table. The attacker will then have ten seconds to establish the connection, before the entry expires and is removed from the connection table.

    It is not even necessary to have logged in the FTP server since the module doesn't check for valid USER and PASS commands. All we have to do is trick the code into thinking we have established a connection (IP_CT_ESTABLISHED+IP_CT_IS_REPLY). To do that, it is only necessary to send any string to the FTP server, which should reply with "invalid command", and then we send the PORT command with our parameters... The FTP server will probably be complaining that a login has not been established yet, but the firewall will have done what we want it to:

    220 tsunami FTP server ready.
    xxxgarbagexxx
    530 Please login with USER and PASS.
    PORT 200,249,193,1,0,22
    530 Please login with USER and PASS.
    QUIT
    221 Goodbye.

    The implications should be obvious -- we outline two main scenarios of attack:

    * The FTP server is protected by the firewall: in this case, the client (attacker) would be on the internet. If the FTP server is compromised by the attacker using other means, the attacker can insert rules allowing the FTP server to:

    Connect to hosts on the internet, for downloading of trojans, tools, reverse tunnels, etc;
    Connect to the firewall itself and exploit it from there onwards;
    Connect to other hosts on networks protected by the firewall, such as an internal network, for example;
    ... use your imagination :)
    * The client (attacker) is protected by the firewall: in this case, the client would connect to an FTP server that he controls on another network such as the internet (as long as the connection passes through the firewall). The attacker would insert rules allowing the FTP server that he controls to:

    Connect to the firewall itself and attack it from there onwards;
    Connect to other hosts on networks protected by the firewall, such as a DMZ or other networks for example;
    ... again, use your imagination :)
    A few observations:

    From my tests, the use of NAT (NAT of the FTP server, NAT of the client and NAT of the target) doesn't stop the attack in anyway. Of course, the attacker will only have to pay attention to which IP he is connecting to, but the entries are inserted into the connection table anyway.
    By default, the ip_conntrack_ftp module only analyses FTP control connections on port 21, so this would only work on connections to FTP servers binding on port 21. Unless, obviously, the module were configured to listen on another port as well.
    This should not need to be said :) but this attack bypasses the firewall rules by inserting an entry into the ruleset for RELATED connections -- for the attack to work, there must be a rule allowing the client to connect to an FTP server (through the firewall) in the first place, and the rule allowing the RELATED state for the specified connection. This is a very common setting, as most firewalls allow their clients to perform FTP, and the too-open RELATED rule is also very common -- i've seen it an lots of IPTables FAQs, guides, lists, etc.

    Solutions

    First and foremost, you should tighten your firewall rules to limit the scope of this vulnerability, by only allowing RELATED connections to the hosts that really need them, and not to all connections.

    The NetFilter core team was notified and quickly developed a patch. It is available at:

    http://netfilter.samba.org/security-fix/
    http://netfilter.gnumonks.org/security-fix/
    http://netfilter.filewatcher.org/security-fix/

    Since it is small, I've included it here:

    diff -urN linux-2.4.3.orig/net/ipv4/netfilter/ip_conntrack_f tp.c linux/net/ipv4/netfilter/ip_conntrack_ftp.c
    --- linux-2.4.3.orig/net/ipv4/netfilter/ip_conntrack_f tp.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 Cris

  11. Re:Open source by Ergo2000 · · Score: 3

    Hey guys, this is open source: there was a security issue with 2.4 - it is fixed now.

    Sure it may have been fixed, just like Microsoft has fixed tonnes of security faults with IIS, but that doesn't seem to stop the tens of thousands of vulnerable machines from waiting to be exploited. This is a big issue because something like a firewall tends to be on machines that you build and forget: My FreeBSD machine was configured, and I've almost forgotten how to configure it. It does the job and it does it well. So in other words even though the source tree somewhere may be fixed, that doesn't instantly fix all the machines out there.

    On a similar note I'm still getting probed for the portmapper TCP 111 fault probably 4 times a day. Where there's smoke there's fire, and this indicates to me that there are a lot of machines out there with this vulnerability waiting to be ownzed.

    So the moral of the story is this: It is largely irrelevant how quickly a patch comes out, because the sad reality is that a lot of people don't actively manage their machines (yes they should but we have to live in reality), so the mere existence of the fault is a serious problem.

  12. 2.4 as a production firewall? by Basalisk · · Score: 5

    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.

  13. Phew! by benspionage · · Score: 4

    First thing I thought was, "oh no not another problem with my win95 firewall" but it's a linux bug, Im safe!!