Slashdot Mirror
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.
Take a look at IPF/IPNAT (*BSD, Solaris, a bunch of stuff, IMHO much better than ipchains/iptables). Too bad it doesn't run on linux. Oh well, openbsd is really easy to install/experiment with. Please don't take this as a linux-flame, I honestly think you would profit from taking a look at something that runs IPF/IPNAT.
Of course, the only articles about MS ever posted on /. are along the lines of "Another bug" "MS Sucks" or "Windows Sucks". Just because that's all /. reports doesn't mean that that is all that happens.
If Linux development had deadlines (MS has them, even though they break them, they still get stuff done sooner) it would have alot more bugs in it at release time as well. You can't squash them all.
Linux is not bug-free or 100% perfectly secure either. If you think it is, you're going to have alot of problems. Ignorance == Stupidity.
It just goes to show you that you can't trust any software that is new and hasn't been tested much. Be it a new Linux kernel or a new Windows version. Both will be found to have bugs. You haven't heard of cracks in ipchains lately have you?
Firewalling is a well-known technique for "improving security". But
a lot of security folks just does not understand that a firewall isn't
the "brick wall" they tend to think it is. Any firewall can be
penetrated, often through the configured "holes" (i.e., TCP traffic at
port 80 etc.). The best practise is to consider your network just as
insecure with a firewall as without a firewall. Then, but only then,
does the firewall give you the protection you think it does.
Of course, this makes you wonder why a bug in the firewall
implementation in Linux makes this large headlines. You shouldn't rely
on you firewall anyway. And when gnome is included in the Linux
kernel, everything will be bloated and insecure. The survivors will be
those that didn't depend too heavily on their Linux firewalls.
the patch to fix is is right 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 Cristiano Lincoln
+ * Mattos for the report.
+ */
LOCK_BH(&ip_ftp_lock);
if (htonl((array[0] tuplehash[dir].tuple.src.ip) {
@@ -197,13 +202,8 @@
info->ftptype = dir;
info->port = array[4] tuplehash[dir].tuple.src.ip));
+ UNLOCK_BH(&ip_ftp_lock);
+ return NF_ACCEPT;
}
t = ((struct ip_conntrack_tuple)
found that sucker out on the net :-)
Nope, this is in the Developers section. /. has sections whose articles are shown with different colors (BSD: red, AskSlashdot: gray, and Developers: blue. There may be more)
I realize that you could set up iptables to deny RELATED connections to reserved ports, but in the case of ip_conntrack_ftp specifically why add them at all? I haven't had a chance to brush up on RFC959, so I could be wrong, but it seems like we could reasonably assume that no legitimate connection will request a PORT or PASV connection to a reserved port, so why place them as RELATED?
> um... wasn't the potential danger here obvious? I'm not trying to be insulting or
> anything, but this was hardly a subtle or complicated hole. "we want to introduce a
> way for the firewall to open and close ports on-the-fly, and in response to client
> actions, and requiring coordination between the firewall and various apps and
> daemons... hmmm what could go wrong with this?" And, what could go wrong is, the
> client might lie. omigod! who coulda thought of that!...
Here's what you missed: the client can already connect to machines behind the firewall, because it, too, is behind the firewall.
So, it can enable outside machines to connect directly. There's little added danger in that. But it's this "behind the firewall" thinking that lead to the error in the first place.
> so, my point is, if this one snuck through, do we have any sense that more subtle errors
> have not been made?
I guarantee there are other errors (20,000 lines of kernel code; you don't need to be a genius to figure out that there are bugs). A small subset of these will be exploitable in some way. A subset of these will expose *you* to something you didn't want.
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.
Sorry, but the world simply doesn't work like that ..
--
Why pay for drugs when you can get Linux for free ?
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
No ssh in any standard browser. Nuff said.
This is your sig. There are thousands more, but this one is yours.
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.
correct me if i'm wrong, but was the original poster of the ipf/ipnat thread talking about JUST THE TOOLS?
i presumed they were referring to the entire packet filtering architecture in the *bsd kernels, not the tools themselves. am i totally off in the weeds here?
Peter
Scroll down to the bottom of Slashdot and search for Microsoft. Secure my ass.
"It's here, but no one wants it." - The Sugar Speaker
You forgot "Your Rights Online," which is colored similar to what the $CHILD_PROCESS produces when she barfs up her strained peas.
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
You cant trust all this free mumbo jumbo, give me a nice secure copy of windows any day
I think everyone using windows has been saying "give me a nice secure copy of windows" for quite a while
http://Lenny.com
Slashdot will not change their logo to blue until Kmart agrees to a sufficently large payment. Then it will be flashing blue for ten minutes at selected times during the day.
Somebody pour me some hot grits.
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.
BTW I highly recommend O&M to the hackish crowd =)
--
Well, thats nice - but I have to say KDE and Gnome have never caused problems for me like Windows has. Also, when you do your creative work at home, why would you want to be subjected to Windows? Linux is much better usited to editing digital audio than windows - if the software existed, and that is what we are trying to change. there certainly is nothing about DOS that makes it better for this. SGI has switched to Linux from IRIX - and there is a version of Maya available now for Linux. How long do you think video editing will be a problem? how about all the custom video editing sysatems based on BSD (I know thats 'work', but...) There is no such thing as a 'server' os or a 'desktop' os. there are only desktop applications and server applications. Microsfof has nothing to do with it. Microsoft developing for Linux would do nothing until Linux was crammed down their throats like every MS product. people do not use microsoft products by cohice : 90% of the users would use whatever is on their computer when they turn it on because they are clueless.
Juln
and vice versa - once people port to os 10, they can go to linux with not too much more effort, relatively.
Also, one an app is ported to Linux Os 10 can follow ! this is going to be good, I hope. I think there will be a bit of Linux>0S 10 ports, not only the other direction. Linux currently is accruing much more crediblity in the business world than Macintoshes have had, because of the unix background for linux, and its stability and no nosense attitude. Also, having a user base that exceeds Apple helps now, also...
Juln
How do you know it's not? How do you know Windows doesn't have the same problem in its Internet Connection Sharing?
At least we know it has been fixed in Linux.
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Perhaps I am reading the patch wrong, however it seems to me that the patch only protects other hosts, you out still add related connections to the same host, you were ftping to.....
James
IPfilter was ported to Linux some time ago, but it is not maintained.
With the new Netfilter framework, it should be much simpler to port IPF to Linux and easier to maintain. This would certainly be a good thing.
Hey guys, this is open source: there was a security issue with 2.4 - it is fixed now.
Tell your friends about xenu.net
He's right. OpenBSD doesn't run any daemons by default, making it secure by default. However, if you run apache on OpenBSD, and there's a hole in apache, your OpenBSD system is no longer secure. Tbus "OpenBSD is secure until you use it for anything practical."
That was not "Overrated".
------
Java-based SSH1/2 client
Stick it on your web page somewhere, and then you've got a client wherever you go!
I actually prefer the blue to the green.
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
I think this is the best prove that people actually read the articel before they post... well, unless it's already slashdoted.
Quite simply because I'm more familiar with Linux and I wasn't aware a BSD solution existed. I needed a software solution with full NAT and firewall, and I knew it was available in linux 2.4. And, frankly, we haven't had any problems with it at all. No crashes, unexplained slowdowns, or weird security problems. This issue actually doesn't affect me at all, since I don't use conntrack_ftp on this firewall (no FTP servers behind it), but I'm patching it anyways in case we use it in the future.
Now that I know a BSD solution exists, I'll make a note of it. But since we're not having problems with this setup, I'm not inclined to move it to BSD. From the department of redundancy department, if it ain't broke, don't fix it.
-Todd
---
"The details of my life are quite inconsequential..."
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..."
Heh, well, it is in Brazil.
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:
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
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.
[
Go away, troll.
You could say that the problem is both acknowledged and fixed.
Why do I say FUD? Because there's a world of difference between a DoS and a DDoS.
Unless there's some mechanism in this overflow that allows one to elevate privelege level which the report and MS both neglected to mention?
P.S.: Linux' firewall product has a hole in it that allows attackers to use it to mount a DDoS. Like Microsoft's hole, it's patched. Wasn't this my original point?
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
Now I can see why the guys working on Mandrake Firewall are not yet using 2.4 for a production firewall! At first I thought that having a stateful firewall would have be worth it, but more testing has to be done before anyone makes it production.
Mike Roberto
- GAIM: MicroBerto
Berto
Just out of curiosity, why didn't you use a BSD solution, which has full NAT capability (and many more) while also being very well tested?
Jeremy
--
Looking for a Python IRC bot?
The article's slow to load... so, as far as I can see, the problem is/was:
E feel free to correct me if I've got it wrong.
GROGGS: alive and well and living in
Are there any realistic alternatives to ftp? It would be great if we could get past the flawed ftp architecture entirely, rather than hiding some of its problems by tunnelling it inside ssh. If you had unlimited time and resources, how would you redesign ftp to make it more secure? For example, maybe you would get rid of the wasteful dual channels, and put data and control messages in a single channel.
I am not a lawyer.
I disagree. You have to weigh the benefits with the risks. Not every network needs 24/7 Internet access. Can you afford 99.9% uptime instead of 99.99? Are you firewalling servers, or a corporate workstation subnet? If it's the latter, you almost certainly would want to be using the 2.4 kernel at this point.
If you need 4+ 9's uptime, then yes, I would definitely be sticking to the 2.2 series kernels. You Know It's Going To Work. But when you can afford a little downtime, the benefits of using 2.4 + IPTables certainly outweighs the risks. (I won't list the advantages here, as they are numerous, and we all know what they are.)
signature smigmature
- James
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.
i thought i'm lost already :(
A good Win32 firewall product is WinRoute Pro. It does all the communication and takes the OS out of the equation. Of course don't go with the default install but it can be made reasonably secure. I have installed it in a small installation in the past and considering they were going to use nothing, I felt better about using this. I'm glad I was just consulting at the time and didn't have to deal with it 24/7. Personally my own firewall uses IP chains.
At my current job, we use a commercial firewall product but use OpenBSD bridging firewalls internally to protect the internal network segments. You security better not be all in your firewall because all firewalls can be broken given enough time and skill. Lock down the routers, switches and for the love of God, lock the server room door(s). Remove every modem in the network and use a modem pool if there is some reason to have one at all. Put a firewall between the modem pool and the network and lock it pretty hard. Never underestimate the power of users (or sysadmins) to circumvent the security with postit notes, leaving critical systems logged on, leaving doors open to the public, etc.
Passive is just about as bad.
;).
;) ) clients seem to take full advantage of the protocol.
I don't want to allow my internal clients to open connections to just about any port outside.
On the flip side if at my site I'm running an FTP server in passive mode, how do I protect it?
FTP is a bad protocol for firewalls. But RPC, RMI, H.323 are even worse
I don't know why they had to design FTP that way. Few (legit
Might as well switch to HTTP.
Cheerio,
Link.
Just because its _supposedly_ very well tested, doesn't mean security is guaranteed.
:).
;).
For example IPfilter also recently had a problem - it was passing fragments through, even when not supposed to.
And IP filters was supposed to be quite well tested.
It didn't affect the site I set up because I don't allow packets through at all - everything is proxied. I do run IPfilter but it is just to log attack attempts, and help make sure things are safe even if accidents happen
The router in front is also configured to do packet filtering. Most of the kiddies don't even get through the router filters, hardly see any attacks on the ipfilter logs.
All these precautions have been justified by the recent IPfilter flaw.
So if you really want to be safe layer your firewalls and don't use the same stuff. Try iptables if you want, but have something else behind it. And make sure the ISP-facing router in front is secured and also doing some filtering.
And don't run BIND or Sendmail. Both have been very well "tested" by people over the years
Cheerio,
Link.
I agree, people use windows because they're forced to. The OS runs on the cheapest hardware available (x86 is the cheapest hardware in the PC market) and has the most drivers and compatibility out there. I have tons "special" hardware that nobody plans to have it working with linux any time soon. I've researched it and wished I could get rid of windows long ago, but it's never going to happen. My best bet is to hope the OSX gets stable and bit the bullet and pay the big bucks for a good dual G4 or something. At least Apple is delivering desktop solutions. Linux is attempting, but failing to do what needs to be done to make it a desktop.
.. but thats it. It will get a few more here and there I'd imagine, but ONLY because OSX is out and people are porting things to OSX. They probably figure, well we need to port to OSX anyways, so we might as well port it to linux now too ....
My point it, either do what apple did and put something out that is awesome that everyone will back, or give up. KDE and GNOME both suck. I liked afterstep or enlightenment better. As far as use ability and the way the GUI looks KDE and Gnome are worse than both MacOS and Windows. OSX rocks, it's just slow, but it will get it together but the main thing is it's good enough for corporate programs to back it and will put out commercial products that will be stable for OSX. Linux doesn't have much support for that.
Yes, linux has MAYA
So linux is riding off of OSX whether they believe it or not...
Did this patch make it into redhat 7.1?
Daniel
Dunno, if Microsoft were to immediately acknowledge the existance of a security vulnerability and offer a patch that worked within a few hours or days of the alert...
I would still bitch and moan!
---
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Looks like it's time to go back to ZoneAlarm.
(since the site seems almost slashdotted a copy is made below)
/proc/net/ip_conntrack), of the following form:
/proc/net/ip_conntrack), of the following form:
:)
:)
:) 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.
f tp.c linux/net/ipv4/netfilter/ip_conntrack_ftp.c
f tp.c Fri Aug 11 05:35:15 2000
/* Update the ftp info */
/*
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
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
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
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_
--- linux-2.4.3.orig/net/ipv4/netfilter/ip_conntrack_
+++ 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 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
i totally agree. if only the slashdot image on the banner bar would be blue. hey slashdot folks, how about giving use some color options? that green reminds me of the default background for win98--, ick..
I also noticed there is a patch for it on bugtrax already. How many of MS buggs are still wide open and well known?
The truth shall set you free!
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.
I am surprised that FTP hasn't been completely abandoned by now, considering the hoops that firewalls have to jump through just to support it.
where there's fish, there's cats
Don't use ftp! If it's anonymous access you want, just use apache. If it's account based access, by all means DON'T use ftp -- can you say clear-text authentication? It seems like I'm always hearing something security related concerning ftp usage. Whether it be the daemons, the clients, the firewall, it is always something. I wish the major clients (including gozilla) would support sftp. Maybe they do, but I missed it.
I'm pretty sure Linus did not write netfilter.
http://netfilter.samba.org
Core Team: Harald Welte |James Morris |Marc Boucher | Rusty Russell
"Why didn't I join Microsoft? [LAUGHTER]"
Word mslinux up.
Moving at the speed of government.
2.4 is a fairly new system, and people have been warned about using it directly on the Internet in favor of 2.2 code. The identification and quick fixes to this problem show the Linux community's ability to identify, admit, and fix problems. Microsoft has trouble with all three of those things, and is forever updating an unending string of service packs to fix problems while creating new ones. No OS has ever claimed to be secure, especially when you are talking about insecure protocols and applications, but the evidence shows that Linux (and Unix in general) has the lead over Microsoft in security. If you really want to talk security, you have to be willing to lose some features. A fully secure mail system will kick out many valid messages and isolate your network to the point of non-useability. If you have to use FTP, then you have to use ftp -- knowing full well that passwords and data are sent unencrypted.
Click here or here.
I was just about to post the same thing! Maybe someone's been messin' with their IP tables ;)
First thing I thought was, "oh no not another problem with my win95 firewall" but it's a linux bug, Im safe!!
SSH. Nuff said. -- blah
You do have a point here. FTP is screwy, and it's the bane of firewalls. PASV doesn't seem widely used though, so it's kind of like tilting at windmills to require its use.
FTP should have been implemented as a single-connection protocol, IMHO, but it's too late for that. There's always HTTP, but that seems a bit lacking in file transfer features for it to actually replace FTP. We'll just have to live with the problems of FTP, which includes, for Linux 2.4 firewall administrators, patching (and using) ip_conntrack_ftp.
Select 'light' in your preferences.
Then you won't see post numbers either, so 'First Post' enthusiasts look like idiots.
Then add:
127.0.0.1 images.slashdot.org
127.0.0.1 ads.web.aol.com
To your host table and you'll not see banner ads or graphics, either.