Re: Cisco PIX bug, discussions (lenghty)

[Eric Vyncke <evyncke () cisco com>]

[First of all note my affiliation, even if I speak only for
myself]

At 15:01 24/08/98 +0200, Robert Ståhlbrand wrote:
> Here is some other part of the discussion which might be interesting for
> this list.
> Please have comments...

You ask for comments, so let's go...

I will focus mainly on the router side (any firewall should behave
in another way, else it is a bug in the firewall!).

You are right by saying that the most secure way of applying ACL
is to defragment all IP datagrams.

But, from my personal perspective, this is not really desirable
on a router:

Well known reasons:

0) this is not mandated for a router, defragmentation is mandatory
only on a host

1) there is a performance penalty (copying fragment parts, ...)
and in most of the case, the defragmented IP datagram will have
to be fragmented again before retransmission !

2) there is a huge impact on the needed memory to keep all those
fragments (< IRONIC> who said that Cisco memory is expensive ? </IRONY>)

3) the defragmentation process will, in all cases, be subject to
DoS attack which could possibly make your router CPU 100% busy

Now, the more serious reasons:

4) latency will be increased. The transfer time of a complete IP
datagram (including voice over IP or any real-time over RTP/UDP)
across a network can be computed as: 

   - without reassembly in routers: serialization time of the complete packet 
     (all fragments) on the slowest link 
     + queuing delay in all routers for one fragment
     + serialization time of the biggest fragment on all links.

   - with reassembly in routers: serialization time of the 
     complete packet on all routers
     + queuing delay in all routers for all fragments

The transfer time is thus much more important when all and every
transit routers make the reassembly. And even if not all routers
apply ACL, you will have probably at least a couple of routers
applying ACL on the path.

5) redundant paths... a firewall is a single point of traffic
concentration, so, a firewall can reassemble all IP fragments because
a firewall `sees' all of the fragments. From a router perspective,
a router may not see all fragments due to load balancing among
links, route flapping, ... so a router CANNOT make IP defragmentation.

Conclusion, for security reason you MUST defragment IP datagrams
at one location (i.e. the firewall), for technical reasons it is
mostly IMPOSSIBLE to defragment in a router.

By the way, I *guess* that all plain routers are behaving
like the Cisco IOS routers. I would appreciate any comment
on this statement.

Now, having said this, we can start the war between application
gateway firewalls (which often rely on host TCP/IP stack for
defragmentation) and `stateful inspection' firewalls (which must
defragment).

And even ask whether any IDS is making defragmentation ;-)

Just my personal 0,50 BEF

Personal flames are expected/allowed ;-)

-eric

> /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:
> ------------------------------------------------------------------------
> ----------------------------
Eric Vyncke      
Technical Consultant               Cisco Systems Belgium SA/NV
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke () cisco com          Mobile: +32-75-312.458