RE: [fw-wiz] CERT vulnerability note VU# 539363

From: R. DuFresne (dufresne@sysinfo.com)
Date: 10/16/02 

From: "R. DuFresne" <dufresne@sysinfo.com>
To: Stephen Gill <gillsr@yahoo.com>
Date: Wed Oct 16 12:02:15 2002

I've looed a bit more at the CERT site. And find a few things
interesting;

First note, there are so many 'unknowns' in the listing, which, secondly,
is far from complete <even fw-1 seems to be missing, and they skip over
some of the linux *bsd distributions>. Then I looked specifically at the
vendor notes for a number of vendors there, Netscreen is listed as
vulnerable, but, their notes state specifically:

<quote>
Vendor Statement

   NetScreen has studied the issues raised in this vulnerability alert.
   With proper configuration of their firewalls, customers can virtually
   eliminate the impact of any of the proposed DoS attacks. Specifically,
   customers are strongly advised to utilize NetScreen's SYN Flood
   protection and UDP rate limiter. On some platforms, default timeout
   parameters might need to be changed in order to have a more consistent
   response to these attacks. Please refer to NetScreen's support site
   for more information.

</quote>

Of course on another note of interest, most the vendors seem to be
responding only to the tcp/upd 'syn' flooding issue raised, and are
ignoring Stephen's crc bypass flood. I only noted IPFilter directly
addressing this, though I admit I did not check each vendor response
<though, then again I maywell have since so many are listed as "unknown">.

Cray is listed here, seperate from SGI, who, according to my last
information owned cray, so this seems strange <perhaps cray's been resold
outside SGI in the past few years and my information is old (?)>:

<cray quote>

Vendor Statement

   Cray, Inc. is not vulnerable as we provide no software that performs
   this type of function.

</unquote>

<SGI quote>

Vendor Statement

   No statement is currently available from the vendor regarding this
   vulnerability.

<unquote>

I see cray always listed in these certs as not having an issue cause they
don't provide anything in the category to 'handle' these things. Course
their TCP/ip stack is still sitting there, as much as SGI's stack has to
be, at least the SGI side has decided to not prvide vendor input at this
point.

Sadly, it seems one can't fully trust the vendors statemnts in some cases,
and sadder yet, folks would have to actually read the statemtns to see if
they reflect what CERT claims about the vendors status <if we acept
netscreens claims on the single side of the 'two' attack methods
discussed>.

Thanks,

Ron DuFresne

On Wed, 16 Oct 2002, Stephen Gill wrote:

> Sadly and amazingly the TCP/SYN flood isn't handled well. Or at least
> wasn't when the paper was written. Hopefully things have improved
> somewhat in some vendors.
>
> -- steve
>
> -----Original Message-----
> From: R. DuFresne [mailto:dufresne@sysinfo.com]
> Sent: Wednesday, October 16, 2002 8:52 AM
> To: Stephen Gill
> Cc: 'Mikael Olsson'; firewall-wizards@honor.icsalabs.com
> Subject: RE: [fw-wiz] CERT vulnerability note VU# 539363
>
>
> Of course the attacks mentioned in this CERT advisory are not really
> traffic limit overloads, but, resource exhaustion techniques. The
> tcp/syn
> flood method of exhhaustion should be well handled by most firewalls
> these
> days. But, the newer CRC related method is something even more
> interesting. And seems to support the claims of Marcus and Mikeal and
> Paul and others about the real depth and breath of the packet logic in
> filtering and stateful as well as proxied gateways. From how I read the
> CERT, it seems you can have speed and performance, or you can have a
> full
> examination of the packets and all their settings, but, perhaps not both
> at the sametime, so vendors shoot for the former.
>
> Thanks,
>
> Ron DuFresne
>
> On Wed, 16 Oct 2002, Stephen Gill wrote:
>
> > In my opinion if a stateful firewall claims it can filter at rate X
> > (64byte packets, etc...), it should be able to filter at that rate
> under
> > all conditions. Clearly a 100MB firewall that can be overloaded with
> > 1MB of traffic is not good. I'd argue that if a 100MB firewall can be
> > overloaded with 34MB of traffic, it's also not a good thing. But then
> > again, even 100MB of filtering won't save you in a 100MB DoS which is
> > not all that uncommon.
> >
> > I'd like to learn some of the other methods being used for mitigation
> > amongst vendors.
> >
> > -- steve
> >
> > -----Original Message-----
> > From: Mikael Olsson [mailto:mikael.olsson@clavister.com]
> > Sent: Wednesday, October 16, 2002 7:44 AM
> > To: Stephen Gill
> > Cc: firewall-wizards@honor.icsalabs.com
> > Subject: Re: [fw-wiz] CERT vulnerability note VU# 539363
> >
> >
> > Stephen Gill wrote:
> > >
> > > Thought I'd pass this along.
> > >
> > > http://www.kb.cert.org/vuls/id/539363
> >
> > Although this is something that people need to keep in mind when
> > picking / designing a firewall, I'd argue that anything north of
> > a stateless packet filter is going to be vulnerable to these sort
> > of attacks.
> >
> > If you keep state, you will be vulnerable to state table overflows.
> > Period. The only real question is: how much work does the attacker
> > need to put in before it becomes painful for the networks that the
> > firewall is protecting? Is being able to resist a 1 Mbps stream
> > (~4500 pps) "Not vulnerable"? Is being able resist a 34 Mbps stream
> > (~150 kpps) "Not vulnerable"? Or should every single firewall
> > vendor report in and say "Vulnerable", and describe what the limit is?
> >
> >
> > And, yes, ALG-only firewalls can also be overloaded. It's just a
> > different type of 'state'.
> >
> >
>
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart
testing, only testing, and damn good at it too!

Relevant Pages

  • RE: Whose X do I need to X to get on CERT?
    ... I was extremely impressed with their responsiveness and we had our ... Whose X do I need to X to get on CERT? ... When CERT's recent SNMP advisory came out ... On its major advisories CERT advertises a "Vendor Information" ...
    (Bugtraq)
  • [fw-wiz] OBSD reaction to CERT advisory
    ... such as a CERT vulnerability note, ... did the first or second time around (We've gone from SACKs to TCP ... Between this, misspelling Mikael's last name, and the fact that his vendor ... and writing it in the first place makes the OBSD team look like ...
    (Firewall-Wizards)
  • Re: [fw-wiz] Variations of firewall ruleset bypass via FTP
    ... > only a single vendor listed as "vulnerable". ... > minutes ago fixed that vendor's vulnerability. ... Would I like to see which firewalls failed testing? ... > listed in the CERT advisory, therefore, is *not* helpful to me. ...
    (Firewall-Wizards)
  • Re: [Full-Disclosure] CERT, Full Disclosure, and Security By Obscurity
    ... >> With the recent evidence that CERT informed it's paying members about ... >> the Sapphire SQL worm before the rest of the world should now indicate ... CERT told me that is what they wanted to do when I ... > [other than the vendor]) anymore. ...
    (Full-Disclosure)
  • Re: Why most run Microsoft, not RedHat
    ... We have an enterprise grade firewall behind the router. ... Any respectable AV vendor will have a sample the moment anyone reports it. ... She knows about dubious emails. ... Would you know if it was sending a few pieces of spam email now and then - or making a few web site hits to run up someone's ad counters? ...
    (Fedora)