Cisco PIX bug, discussions

[Robert Ståhlbrand <robert () nmac ericsson se>]

Here is some other part of the discussion which might be interesting for
this list.
Please have comments...

/Robert Ståhlbrand, Ericsson Telecom AB

------------------------------------------------------------------------
--------------------------
Hi!

Didn't know that packet filtering routers (Cisco of course) did the same
thing as the PIX but it was easy to guess.
I've had a long and interesting discussion with several persons at Cisco
and they at first said the same thing as to you and claimed that there
are several problems by letting the PIX take the hit. My opinion is that
is it always the firewall which should take the hit or you have
misunderstood the concept of firewalls!
Another thing is that it would not nessecery be a problem in booth the
PIX and in the IOS cause Cisco (from what I have undertood) did buy the
PIX concept from a small company.

The problem are (Cisco claims) that it takes a lot of CPU, memory and
buffer to reassamble the packet on the firewall. In this case you would
move the DoS-attack to the PIX itself!
Yes it would eat some CPU, mem. and buffers but correctly implemented
this wouldn't be a too big problem. Maybe you have to do things like
throw fragments if not the initial packet has been recieved within 2
second or so. If the packet should be dropped just make the firewall
"remember" the fragment ID for 5 seconds and drop every packet which has
this ID. When 5 seconds has passed the fragments will be kept in 1
second and treated like it was waiting for it's initial TCP-packet and
so on....The new attack-method would be to flood the firewall with
fragments with different ID:s but with right design and the possibility
to configure this parameters by the administrator it would be prevented.

I think the problem is a architectial one and it would take a long time
for cisco to fix.


Robert Ståhlbrand, Ericsson Telecom AB
Network Managemnt Application Center
TeMa-Lab System Responsible, Systems & Technology
Flöjelbergsgatan 2A
Box 333
SE-43124 Mölndal
Sweden
Telephone:      +46 31 7476162
Mobile:         +46 70 9876162
fax:            +46 31 7472942
robert () nmac ericsson se

"Real hackers don't die, their TTL expires."

> -----Original Message-----
> From: matt [SMTP:matt () saratoga its bond edu au]
> Sent: den 20 augusti 1998 00:01
> To:   Robert Ståhlbrand
> Cc:   aleph1 () dfw net
> Subject:      Re: [BUGTRAQ]       Serious bug in Cisco PIX
>
> hi robert,
>       i along with you reported these problems to cisco nearly a year
> ago now ( i can dig out the auscert case numbers and ciscos response
> if
> you want ) 
>
> basically we were finding clients were being ping flooded on the other
> side of a access list on a cisco router, because the cisco does not
> "defrag before process" (like you can do on a linux packet filter) we
> found that say a 9k packet fragged into 6*1.5k frags, the first frag
> would
> stop at the router, the remaining 5 frags would pass across the
> customers
> link and be discarded by their router as bad packets (never the less,
> the
> damage is done)
>
> ciscos word on it was "we won't be fixing this" basically yet myself
> and
> the auscert personell agreed the problem could have serious
> ramifications
> in the future.
>
> aleph,
>       this probably isn't worth going to the list because it basically
> says what robert has said, however i believe that if you go back
> through
> the archives, there are some examples on walking through non stateful
> filters and establishing connections with NT boxes. this (if i recall
> rightly) was due to the way that NT refrags the packets when it
> processes
> them. if i recall rightly, because NT does it very poorly, you can
> trick
> the sequences so that you make the first packet a "dummy" packet and
> the
> real first packet gets wacked on the end, when NT refrags, it places
> the
> real first packet (which was allowed straight through the firewal) in
> order and presto, one established connection to the internal network.
>
>
> On Wed, 19 Aug 1998, [iso-8859-1] Robert Ståhlbrand wrote:
------------------------------------------------------------------------
----------------------------