Fragmentation Attack

Fragmentation Attack

[Gandalf The White]

Greetings and Salutations:

I have been directed to this mailing list for discussion of something I
worked on.  I am hoping that given the specifics that the Linux OS can be
fine tuned to fix this issue.

I recently received my GCFW (GIAC Certified Firewall Analyst) certification
from SANS.  Part of the certification requires completing a "practical", a
security paper.  In the certification we are required to "attack" another
practical that has been previously passed.  While working on this portion of
the paper I came up with (I believe) a unique DoS (Denial Of Service) attack
that affects the operation of most operating systems, but in this case we
are discussing Linux.

The "Rose" attack (as I call it) is described at:
http://digital.net/~gandalf/Rose.rtf

A summary of the attack:
1) The first (very small, 30 bytes) fragment of a ICMP packet is sent.  This
is offset 0 with the complete and correct ICMP header
2) The last fragment (again, very small) of a 64k sized fragment is sent.
3) This process is repeated with a UDP packet and a TCP packet

The end result is that on my 450 MHz Linux box the CPU utilization went to
100% utilization.  I had a fragmented ping from another computer running at
the same time, most fragmented pings were replied to, a few were missed.
The Linux box I was "attacking" returned to normal when I stopped the
attack.

The other interesting feature of this attack that I have seen is that the
source IP address and the source and destination port do not matter.  On any
device.  Since the packet is never fully assembled the upper levels of the
IP stack never validate that the destination port is valid.

I also noticed that different machines handled the ICMP reassembly Time
Required error packet differently, thus this could be used for OS
fingerprinting.

I have cleaned up (revisited) the attack since I wrote the paper.  As
written the original will work the same as my cleaned up version (but below
is the "technically correct" version).  I fixed my input into the nemesis
program (as written in the above paper) as follows.
See http://www.packetfactory.net/projects/nemesis/ for the software:
nemesis icmp -S 10.3.64.121 -D 172.16.1.100 -d1 -i 8 -I 7242 -P
Picmpdata.txt -FM0
nemesis ip -S 10.3.64.121 -D 172.16.1.100 -d1 -I 7242 -p 1 -P Picmpdata.txt
-F8100
nemesis tcp -S 10.196.212.207 -D 172.16.1.100 -d1 -I 2153 -s 2494456820 -x
36961 -y 63398 -P Ptcpdata.txt -FM0
nemesis ip -S 10.196.212.207 -D 172.16.1.100 -d1 -I 2153 -p 6 -P
Ptcpdata.txt -F8100
nemesis udp -S 10.195.74.172 -D 172.16.1.100 -d1 -I 6316 -x 13253 -y 20460
-P Pudpdata.txt -FM0
nemesis ip -S 10.195.74.172 -D 172.16.1.100 -d1 -I 6316 -p 17 -P
Pudpdata.txt -F8100

For testing I generated a Excel spreadsheet to put random values for many of
the fields above (source IP, Sport, Dport) and thousands of packets to test
against the Linux box. I ran the test using nemesis (which is, of course,
too slow to affect the Linux box) and captured the packets using netwox54 :
See http://www.laurentconstantin.com/en/netw/netwox/ for netwox.

After that had finished running for about 9 hours or so I was able to dump
the captured packets back out all at one time using netwox54 again.  This is
where the DoS took place, throwing all those packets at the box at once.

If you want step by step instructions I can provide them.

This is FYI, I am hoping that protection against this attack can be found.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html

Re: Fragmentation Attack

[David S. Miller]

On Sat, 07 Feb 2004 11:36:14 -0600
Gandalf The White <gandalf@digital.net> wrote:

> If you want step by step instructions I can provide them.

What makes your DoS interesting is whether the attacker needs
a lot of bandwidth or not.  Ie. if he has to be sitting on your
gigabit subnet then the attack isn't interesting.  Whereas if he
can eat all of the remote systems cpu cycles just being behind a
cable modem, that's interesting.

Which is it?

Also have you done your cpu utilization tests on something a little
less ancient than a 450mhz system?  How fast was the network?

Re: Fragmentation Attack

[Gandalf The White]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

Greetings and Salutations:

On 2/7/04 11:45 AM, "David S. Miller" <davem@redhat.com> wrote:
> What makes your DoS interesting is whether the attacker needs
> a lot of bandwidth or not.  Ie. if he has to be sitting on your
> gigabit subnet then the attack isn't interesting.  Whereas if he
> can eat all of the remote systems cpu cycles just being behind a
> cable modem, that's interesting.
> Which is it?

The network that I was working on was a 100Mb network.  This is (of course)
lots of packets at one time.  Attached is the excerpt from paper, I was
sending somewhere around 780 packets Per Second (I didn't know if
attachments were allowed to the list at first, but I saw a attachment in one
of the e-mails).

The requirements of the attack (from the perspective of the paper I wrote)
was that you had taken over 20 cable modem computers.  From this viewpoint
this could (of course) produce the required number of packets IMHO.

Of course you could also clog up the bandwidth of just about any destination
network with this requirement, but that is a different DoS.

> Also have you done your cpu utilization tests on something a little
> less ancient than a 450mhz system?  How fast was the network?

Well, that was my problem.  I didn't have much equipment to work with which
is why I sent it out to a list like this.  I was hoping that someone else
would be able to do a test on the equipment that they had and verify my
results on different equipment.

I noticed on the ICMP reassembly required timeout that the packets returned
were from IP addresses that were in different parts of the attacks (it
helped that I put random source IP addresses in the file).  It was almost as
if some of the packets I had sent to the Linux box were dropped during the
attack.  But again this could easily be a function of the slow CPU of the
box.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html



[-- Attachment #2: Rose.rtf --]
[-- Type: application/msword, Size: 91637 bytes --]

Re: Fragmentation Attack

[David S. Miller]

On Sat, 07 Feb 2004 12:00:42 -0600
Gandalf The White <gandalf@digital.net> wrote:

> The requirements of the attack (from the perspective of the paper I wrote)
> was that you had taken over 20 cable modem computers.  From this viewpoint
> this could (of course) produce the required number of packets IMHO.
>
> Of course you could also clog up the bandwidth of just about any destination
> network with this requirement, but that is a different DoS.

Yes, but this very fact makes the "DoS" much much less interesting.
If I can clog your link anyways with arbitrary traffic, who cares
what it does as a second order effect, the machine is made unreachable
and unusable either way.

Also, these half-complete ICMP packets are really super easy to create
firewall rules for to block them at ingress of a major site.

Re: Fragmentation Attack

[Gandalf The White]

Greetings and Salutations:

On 2/8/04 2:45 PM, "David S. Miller" <davem@redhat.com> wrote:
> On Sat, 07 Feb 2004 12:00:42 -0600
> Gandalf The White <gandalf@digital.net> wrote:
>> The requirements of the attack (from the perspective of the paper I wrote)
>> was that you had taken over 20 cable modem computers.  From this viewpoint
>> this could (of course) produce the required number of packets IMHO.
>> 
>> Of course you could also clog up the bandwidth of just about any destination
>> network with this requirement, but that is a different DoS.
> Yes, but this very fact makes the "DoS" much much less interesting.
> If I can clog your link anyways with arbitrary traffic, who cares
> what it does as a second order effect, the machine is made unreachable
> and unusable either way.

Exactly.  So I was discounting the "clog your connection" attack.  What I
was looking at is if someone has a fast machine that they can send a
regulated amount of packets to and test out the fragment attack that would
be good.  I suspect that this attack would still spike the CPU on a machine
at a relatively low (a few hundred) packets per second rate.  On a web
server or other Internet Facing machine that has a decent load this could be
enough CPU overhead to create a DoS.

> Also, these half-complete ICMP packets are really super easy to create
> firewall rules for to block them at ingress of a major site.

The attack has ICMP, UDP and TCP.  If you were seeing a specific signature
over and over again then I agree that it might be easy to block (depending
on the firewall) ... But ... If someone were sending fragments destined for
port 80 to your web server I don't see how you could differentiate between
"real" fragments going to the web server and faked fragmentation requests.


Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html

Re: Fragmentation Attack

[David S. Miller]

On Sun, 08 Feb 2004 15:12:36 -0600
Gandalf The White <gandalf@digital.net> wrote:

> The attack has ICMP, UDP and TCP.  If you were seeing a specific signature
> over and over again then I agree that it might be easy to block (depending
> on the firewall) ... But ... If someone were sending fragments destined for
> port 80 to your web server I don't see how you could differentiate between
> "real" fragments going to the web server and faked fragmentation requests.

In this day and age, and with all the headaches fragmentation causes
(either directly or indirectly via these resource consumption DoS's)
we may soon be reaching the point where only talking to sites doing
path-MTU discovery (yes, even for UDP) is a valid decision for a big
site.

This would solve the problem in a hurry.

For TCP I think people can do this today.  For UDP, what do you need fragmented
UDP for, DNS queries?  I think not for those types of usage, and even streaming
voice or whatever UDP uses chop up the datastream themselves spitting out a
non-fragmented time transmitted line of packets looking sort of ATM'ish.

Fragmented ICMP should just be blocked at firewall for people concerned about
this, I see no valid use of this.

Re: Fragmentation Attack

[Gandalf The White]

Greetings and Salutations:

On 2/8/04 3:18 PM, "David S. Miller" <davem@redhat.com> wrote:
> In this day and age, and with all the headaches fragmentation causes
> (either directly or indirectly via these resource consumption DoS's)
> we may soon be reaching the point where only talking to sites doing
> path-MTU discovery (yes, even for UDP) is a valid decision for a big
> site.
> This would solve the problem in a hurry.

For good or bad, IPV6 carries fragmentation with it.  Indeed it is a little
further in the header, but fragmentation is still there.

It was my hope that this group would be able to come up with a better
algorithm to (more) efficiently handle IP fragments.  Whatever the algorithm
now it is doing a fairly good job.

Like it or not fragmentation is here to stay for your and my lifetime.  Yes,
I agree that sites would be better off not allowing fragmentation.  They
might be better off doing MTU discovery but that protocol can also be used
to map out networks.

The best solution is unfortunately placed on the software engineers that
design the software.  The software has to be as efficient as possible.  The
engineers can only hope that CPU and / or NIC speed will outpace the speed
at which data is transmitted thereby making the CPU / NIC able to handle
anything thrown at it.

I am a network administrator (I also design and install networks).  I work
with routers, switches, firewalls, VPNs, nothing above layer 4.  From what I
have seen of server administrators in my past I don't have much faith in
them being able to handle "network" problems.  Instead of methodical
troubleshooting many have the "keep stabbing in the dark until it works then
leave it alone" attitude (and they never know why it works when it does).

At many companies these server admins are called "Network Administrators".
They are expected to know how to not only set up servers, but to know how to
run the network (from managements limited knowledge those are the same
things).  To expect them to know such arcane IP concepts as MTU path
discovery and fragmentation is (IMHO) asking too much.  They are lucky to be
able to tell the difference between IP or IPX, TCP UDP or ICMP.

As systems get more and more complex we, the technologists creating these
systems are going to have to simplify and automagically protect users and
administrators from themselves as best we can.  Turn on all the autoupdates
we can and make a standard install start as few services as possible.  Allow
the system administrators with knowledge to shut down autoupdates and turn
up services that they need, but only if they are technically savvy enough to
know to do these things.

My 2 cents worth.

Thank you for listening.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html