Firewall Wizards mailing list archives
RE: CERT vulnerability note VU# 539363
From: "Stephen Gill" <gillsr () yahoo com>
Date: Wed, 16 Oct 2002 11:03:10 -0500
Sadly the information provided from NS is about 1% of what should have been stated. As of May, certain Netscreen versions were vulnerable though fortunately bug fixes and other features were put in place to improve mitigation methods. No mention is made here on what features were implemented or what code/platforms were affected. This is unacceptable. Customers should be urged to upgrade _from_ vulnerable versions. -- steve -----Original Message----- From: R. DuFresne [mailto:dufresne () sysinfo com] Sent: Wednesday, October 16, 2002 10:34 AM To: Stephen Gill Cc: 'Mikael Olsson'; firewall-wizards () honor icsalabs com Subject: RE: [fw-wiz] CERT vulnerability note VU# 539363 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 rateunderall 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/539363Although 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! _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- Re: CERT vulnerability note VU# 539363 Mikael Olsson (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- Re: CERT vulnerability note VU# 539363 Daniel Hartmeier (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- Re: CERT vulnerability note VU# 539363 Mikael Olsson (Oct 16)
- RE: CERT vulnerability note VU# 539363 Ofir Arkin (Oct 16)
- RE: CERT vulnerability note VU# 539363 Stephen Gill (Oct 16)
- Re: CERT vulnerability note VU# 539363 R. DuFresne (Oct 16)
- Re: CERT vulnerability note VU# 539363 Daniel Hartmeier (Oct 16)
- Re: CERT vulnerability note VU# 539363 Paul D. Robertson (Oct 16)