Printable View
Is the current version of Ipchains still vulnerable to packet fragmentation attacks? I.E, using packet fragmentation to initiate a connection with a server on a port that the firewall allows, and then overriding the original service port in a subsequent packet with a service port not allowed by the firewall? Or has this vulnerability since been fixed by Ipchains?
To the best of my knowledge this has been more or less solved. Ipchains can be configured to not allow a packet fragment if its offset is not set to be the end of the previous packet. In this manner, the port field cannot be overwritten. It does not actually reassemble the packet and filter based on the reassembled version, but assumes that no normal packet fragment should arrive with an offset placing it in the middle of the previous fragment.
It is also entirely possible to disallow fragmented packets, although this can cause some problems; not many, since ethernet has all but obsoleted any protocols requiring a smaller MTU, and of the WAN protocols I know of, all can handle the 1500 max ethernet MTU.
A better solution, of course, is to use the connection tracking modules, which automatically reassemble packets in order to aid in the tracking process. Yet another benefit of stateful firewalls over simpler packet filters.
So the short answer is that yes, a packet filter can disable teardrop attacks at the cost of some connectivity issues, but a stateful iptables nearly solves the problem entirely.
Thanks for the reply. I was interested in recreating this vulnerability for the purpose of research. But if this is no longer possible, then I guess I am out of luck.
Striek,
You mentioned that
"ipchains can be configured to not allow a packet fragment if its offset is not set to be the end of the previous packet. In this manner, the port field cannot be overwritten"
Would it be possible then, to configure IPchains to allow this sort of attack? As I said I am interested in setting this vulnerability/attack up in my own lab for research purposes. I have never used ipchains however (Only iptables), so I dont know what the possibilities are.
If this could be done (configuring IPchains to allow this sort of attack), that would be great (well, for research anyways!)
Thanks.
Oh crap... you're using ipchains. I thought it was a name confusion issue...
Ipchains did not include the code which I have mentioned. It would be necessary to set up custom netfilter targets to inspect the appropriate packet byte explicitly. It does not have a target to block these types of fragmented packes IIRC. It can be configured to disallow all fragmented packets, but this also is not the default behaviour.
Ipchains is a stateless packet filter, and so does not reassembe packets before retransmission. The examination of fragmented packets for fragment offsets then rests with the destination computer. The vulnerability which caused teardrop attacks to be possible was patched somewhere around the 2.0.30 time.
I'll give you the long and short of teardrop attacks, if it helps. Essentially, after a first IP packet arriving at a destination host with the "More Fragments" flag set, the host waits for the second fragment. The second fragment is key. When this packet arrives, it is set with a fragment offset *and a packet length* that wil cause the second packet to end somewhere in the middle of the first. So let's assume that Packet A arrives, MF flag set, with a length of 1000 bytes. Packet B then arrives as a fragment of packet A. Its fragment offset is set to 500 and its length to 250 bytes. When copying all the packet fragments into a reassembled packet, let's say it copies from Array Foo (where the packet fragments arrive) to Array Bar (the reassembled packet). Once all the fragments have arrived and been placed in String Foo, it copies the string to Array Bar to ensure a clean array. It needs to know the length of the packet first, but since there is no terminating character at the end of the array, it must calculate the length based on the packet values and offsets that have arrived at Array Foo. So it adds the fragment offset of the last fragment, relative to the end of the first fragment, to the length of the last fragment. This is then added to the length of the rfirst fragment to arrive at the reassembled packet length. So in this case, it would calculate the fragment offset relative to the end of the first fragment to be -500 bytes, since Fragment A begins 500 bytes before Fragment B ends. It then adds the length of the last fragment to this value, arriving at -250, meaning the assembled packet is -250 bytes longer than the first packet. However, iptables/ipchains uses a 32bit *unsigned* integer to represent the packet lengths, and as such cannot represent -250. Instead, it calculates this to be 2^32 - 250, or 4294967046 bytes. It adds this insane value to the length of packet A when it calculates the reassembled packet length. When it allocates enough memory for the entire packet, all available memory is used (assuming you have less than 4 gigs of RAM), causing a denial of service attack, usually a forced reboot or a kernel panic.
This vulnerability was pacthed around kernel 2.0.30 by inspecting the fragment offset as part of the packet reassembly code when packets arrive at their final destination. If the fragment offset places the beginning of Packet B before the end of Packet A, it drops both packets. So kernels before 2.0.30 (somewhere around there) on destinatation systems and ipchains (it was ipfwadmin in 2.0 kernels) running on firewall systems, you can recreate the attack.
This has the added benefit of disallowing other forms of teardrop attacks, such as the one you mentioned where the goal is not a denial of service attack, but the rewrite of the destination port field, causing the packets to be inspected based on a packet which they will not arrive it eventually. It is not the only the fireall that must allow the attack, but also the network stack on the victim. Any kernel capable of running ipchains and not using ipfwadmin will not be vulnerable. 2.2, 2.4, and 2.6 series kernels are not vulnerable to teardrop attacks as the bug which made them possible has long been fixed. This also reduces the need for a firewall which checks for this attack as well.
If I bored anyone with that, sorry. I needed the review as well and the question got me thinking about it. Teardrop attacks are excellent teaching tools in terms of TCP/IP protocol. Not just for the security end, but for the application of knowledge that is required to visualize the attack.
In short, stick to, say, kernels before 2.0.25 for the test network and the attack should work.
I never liked nor used IPChains, just skipped it over it ( didn’t see any benefit other then it was supposed to be easier to learn and manage. )
But after googling a little it appears that the vulnerability you are referring to ( unless it cropped up again and I didn’t find it ) was fixed after kernel 2.2.11??? ( I looked it up yesterday, can’t remember ).
But from what I saw, if you can find RedHat 6.0 ( nothing later ) or similar distro the default install should contain the vulnerability.
Hope that helps.
Although it has also probably been fixed also, I am actually talking about what is reffered to as an 'Overlapping Fragment Attack' which can be used to bypass a firewall by sending a packet with information in the TCP header containing a port number which is allowed through the firewall and then subsequent packets overwrite the original port number with a port number that is NOT allowed through the firewall, effectively bypassing a rule in the firewall not allowing access to a certain port.
I.E. packet sent to target requesting access to port 21, which is allowed to anybody through the firewall. This fragment has an offset of 0. The second packet only contains the first 8 bytes of the header, and overwrites the original requested port 21 [allowed through the firewall] with a request for port 22 [not allowed by the firewall], and overwrites the original port 21 destination request. Packet 2=(Fragment offset = 0; length = 8). The 3rd and final packet contains the remainder of the packet from the second packet and completes the request. Packet 3=(Fragment offset >= 2; length = remainder of packet 2) These are reassembled by the target allowing access to port 22 by a host which was supposed to be blocked by a firewall rule.
I assume this has also been fixed? This was the actual vulnerability that I wanted to set up and research. I know that at one time, ipchains was vulnerable to this attack.
If this has been since fixed, does anyone know at approx. what version it was fixed, and if a previous version can still be obtained?
Thanks.
I suggest looking at changelogs or googling for mailing list archives about it. As for whether it can still be obtained, of course it can. All linux kernel versions since 1.0 have been archived at kernel.org for some time now. You can browse the archive via HTTP at: http://www.kernel.org/pub/linux/kernel/Quote:
Originally posted here by Dr. Psy
If this has been since fixed, does anyone know at approx. what version it was fixed, and if a previous version can still be obtained?
Hope that helps your research. :)
I'm sorry, you misunderstood. I was replying to your post, not Striek's
As I said I never used IPChains, but assumed you were speaking of something like this: [INFOSEG] Linux 2.2.10 ipchains Advisory
That is why I referred you to RH 6.0.
IKnowNot,
Thank You! That was EXACTLY what I was looking for!
Wow, so that was fixed way back in 2.2.10, huh? Nevertheless, this is one of the more interesting vulnerabilities that has come around. This should be easy enough to set up then.
A vulnerability like this is perfect for demonstrating the need for a Network Intrusion Detection System to those that say..."But I have a firewall!..."
This is really a great little exploit. Tell firewall I want access to port 22, firewall says no. Tell it then, that I want access to port 21 with a fragment packet, and firewall says Okay. Send another packet, overwriting port 21 with port 22 and firewall says, okay. Just because it already allowed the connection when you said port 21. The connection is already allowed by the firewall and you overwrite 21 with 22, still goes through. It just totally bypasses the port 22 'only allow from internal network' rule. or whatever the rule might be.
Anyways, IKnowNot, the page you sent is perfect. Thanks again ;-)
P.S./ Sounds like you do know!
While it might sound all very easy you need to remember that you need to do this with every packet in the data stream which is less easy to manage. You would need an SSH client that would ignore or replace the port 22 with port 21 and appropriately fragment each packet into it's three sections in order for this to work.
Doable? Yes. Trivial? Not really.
Additionally, as you rightly point out, it might make it past the firewall but Snort and almost any other NIDS should start alarm bells jangling in an admin's head when it shows the offset framentation of packets.
If I were presenting this I wouldn't try to demo it because of the complexity of trying it. Murphy's Law clearly states that it will work flawlessly until you are in the middle of the presentation to the board and then..... :eek: I would prefer to give a laymans explanation of the issue, why the firewall may fail to detect it and what the host will do with the remaining packets.
A nice little mitigating factor might be used on servers that are publicly available. Employ IPSec to "Require Security" on all ports that are not publicly available but that provide service locally, (within the DMZ). That way anything that "finds it's way" past firewall rules still has the issue of negotiating IPSec via a Pre-Shared Key.... The result... No communication. Should work.... Need to test it in the morning.... Dunno why I never thought of it.... layers, layers, layers...... :D
Damn, aint that the truth! lol!Quote:
If I were presenting this I wouldn't try to demo it because of the complexity of trying it. Murphy's Law clearly states that it will work flawlessly until you are in the middle of the presentation to the board and then..... I would prefer to give a laymans explanation of the issue, why the firewall may fail to detect it and what the host will do with the remaining packets.
Thank you for the input, Definately something to think about.