full-disclosure - Re: Should nmap cause a DoS on cisco routers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2498058C-6B5B-4EF3-ABF1-9A41124A5E79@arbor.net>
Date: Fri, 2 Jul 2010 00:41:23 +0000
From: "Dobbins, Roland" <rdobbins@...or.net>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Should nmap cause a DoS on cisco routers?

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@...or.net> // <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/