Message-Id: <1853F6C0-695F-47D3-946C-60BDAE4CB05D@doxpara.com>
Date: Thu, 1 Jul 2010 20:01:26 -0400
From: Dan Kaminsky <dan@...para.com>
To: "Dobbins, Roland" <rdobbins@...or.net>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Should nmap cause a DoS on cisco routers?

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.

It's funny you bring up SNMP. Do you remember what happened when that  
protocol got fuzzed by the PROTOS guys in 2002?  Every network device  
on the planet pretty much exploded. I will grant you that network  
isolation is indeed best practice, but broken code is not something to  
apologize for or mitigate against.  It's something to apply real  
pressure against.  If we can't get pissed, how is that QA guy supposed  
to block shipment?

(That being said, you'll note 'it's code you just shouldn't run' is  
wrong. First thing's first, the network has to function. We route  
packets with the infrastructure we have, etc.  But products that can't  
survive nmap are likely going to have real problems with actual  
exploit tools, and RCE in routers is not something to risk, 'best  
practice mitigations' or no.)

On Jul 1, 2010, at 7:16 PM, "Dobbins, Roland" <rdobbins@...or.net>  
wrote:

>
> On Jul 1, 2010, at 11:12 PM, Florian Weimer wrote:
>
>> And it's certainly a bug worth fixing.
>
> I doubt it's a 'bug' which can be 'fixed', just the same as sending  
> enough legitimate HTTP requests to a Web server to bring it to its  
> knees isn't a 'bug' which can be 'fixed', but rather a DoS which  
> must be mitigated via a variety of mechanisms.  It would be quite  
> helpful if the original poster would detail the models/types/ 
> versions of the network devices in question, and possibly provide a  
> sample query packet.
>
> Part of the general issue here is the large disconnect between the  
> traditional security research community and the networking  
> community; with a few notable exceptions, there isn't a lot of  
> mutual discussion and understanding, and certainly no understanding  
> of network infrastructure device architectures, best current  
> practices (BCPs), and so forth.
>
> One of the most fundamental BCPs is that one must make use of  
> various network infrastructure self-protection mechanisms to keep  
> undesirable traffic away from the control and management planes of  
> said network infrastructure.  Here's a .pdf presentation which  
> discusses network infrastructure self-protection:
>
> <http://files.me.com/roland.dobbins/prguob>
>
> Firing a bunch of SNMP queries at network infrastructure devices and  
> causing network disruption as a result isn't anything new, it's a  
> well-understood phenomenon with a well-understood - in the network  
> operational community, at least - remedy via making use of the  
> appropriate self-protection mechanisms built into most modern  
> network infrastructure devices.
>
> --- 
> --------------------------------------------------------------------
> 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/

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

Powered by blists - more mailing lists