[c-nsp] Cisco Security Advisory: TCP State Manipulation Denial of Service Vulnerabilities in Multiple Cisco Products

[Eloy Paris]

Hi Gert,

On Thu, Sep 10, 2009 at 03:32:33PM +0200, Gert Doering wrote:

> On Thu, Sep 10, 2009 at 09:22:04AM -0400, Eloy Paris wrote:
> > > But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> > > but all the other interesting stuff (telnet, ssh, ldp) is not there...
> > 
> > In a Cisco Security Advisory that we published last year
> > (http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml), we
> > wrote the following:
> [..]
> > The problem is that historically we've had different internal APIs
> > that applications and services can use to register the ports they need
> > to open. I believe "show control-plane host open-ports" is the latest
> > incarnation and the desired way moving forward but not all applications
> > and services have migrated to it which is why we still rely on different
> > commands.
> 
> Thanks for that insight.  It doesn't *really* enlighten me, unfortunately.
> 
> The "show control-plane host open-ports" command is not available on
> 12.2S, 12.3 main, 12.4 main or 12.2SXF/SXH/SXI up to SXI2.  
> 
> None of the other commands reliably display *TCP* listening sockets.
> 
> So - to summarize this: "the only way to reliably detect what sockets
> the box is listening on is to run nmap against it", right?

Unfortunately, yes.

> <rant>
> This is really embarrassing, for a product shipping in this century...

No disagreement here. For one, this state of affairs puts us (the Cisco
PSIRT) in a difficult situation when we write our Security Advisories
since we don't have a simple, single way to tell our customers how to
check if their devices are affected by whatever vulnerability we are
disclosing.

> 
> (and I can't really see why "how is the service registering for a given
> TCP port internally" should have any effect on "display ports registered
> for services", people are known to have written programs that query 
> multiple data sources and present the result in a concise format...)

I am not privy to the details but I think it's been a matter of
re-writing the existing show commands to use data from multiple data
sources, or moving everybody to a single API and use a single source; it
seems like the latter is what has been chosen.

Cheers,

-- 

Eloy Paris
Cisco PSIRT