Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

["Dobbins, Roland" <rdobbins@xxxxxxxxx>]

On Jul 2, 2010, at 7:01 AM, Dan Kaminsky wrote:

> Permanent DoS's are unacceptable even from intentionally malicious traffic, 
> let alone a few nmap flags. They're unacceptable to us, they're unacceptable 
> to Microsoft (see: MSRC bug bar), and even Cisco PSIRT has shown up on thread 
> desiring to clean things up.

Again, causing the RP CPU to go to 100% due to punted management-plane traffic 
isn't a new phenomenon - it's well-understood amongst network operators, as are 
BCPs which mitigate the risk of such an occurrence.  

Of course PSIRT will ask for details, as they should; my point is that there's 
likely nothing new to see here, and that there are mechanisms available to 
ameliorate either deliberate or inadvertent attacks of this nature.

Even if there is something new, here - which I doubt - it's important that 
folks understand that there are BCPs they can implement to protect their 
network infrastructure devices *right now*, rather than sitting about waiting 
for code to drop from the sky, or whatever.

The original poster asked if this were a configuration issue - and the answer 
is, yes, there are things you can do with your configuration to harden your 
network infrastructure against such things.

> It's funny you bring up SNMP. Do you remember what happened when that 
> protocol got fuzzed by the PROTOS guys in 2002?

Yes, and the PROTOS vulnerabilities were by and large real vulnerabilities - as 
opposed to merely saturating the RP of a given network device with 
management-plane traffic.  Some of them even had the potential for remote code 
execution.

And many of them could be mitigated via BCPs until such time as fixed code 
could be deployed, as well.

> I will grant you that network isolation is indeed best practice, but broken 
> code is not something to apologize for

The issue as described doesn't sound like broken code, although that's 
certainly possible (again, would be helpful if the OP would provide more 
details, at least to PSIRT). 

And I'm not 'apologizing' for anything - rather, I'm pointing out that there 
are ways to defend one's network infrastructure against this sort of thing, 
right now, today, utilizing existing features and functionality built into most 
modern network infrastructure equipment.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@xxxxxxxxx> // <http://www.arbornetworks.com>

    Injustice is relatively easy to bear; what stings is justice.

                        -- H.L. Mencken



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/