Re: Cisco NAT DoS (VD#1)

[jnduncan () CISCO COM (Jim Duncan)]

Blue Boar writes:
> A Cisco security guy posted a message to the list asking that they be given
> advanced warning before posts about Cisco bugs are allowed through.  I
> explained that the nature of the list is vulnerabilities that are still in
> development, but that I would be happy to make sure they got a copy of any
> Cisco-related problems to the e-mail address(es) of their choice.  This was
> all started by this message, so clearly Cisco is aware of the issue.  As
> far as I know, they haven't done anything about it.
>
> There was no further comment on this particular issue, so I'm posting it
> for wider dissemination.
>
>                                                       BB
>
> From:
> http://securityfocus.com/templates/archive.pike?list=82&date=1999-09-8&msg=37
> DA76F7.2B19D7DD () thievco com
>
> > To:           Exploit-Dev
> > Subject:      Cute little Cisco NAT DoS
> > Date:         Fri Sep 10 1999 17:36:23
> > Author:       Blue Boar
> >
> >
> > I was doing some research the other day about Network Address Translation
> > (NAT) on a cisco box.  The configuration I was using when I found this
> > problem was NAT overload. I had an inside net, 192.168.0, and a Windows PC
> > sitting at 192.168.0.2.  The outside interface was another ethernet (the
> > were both FastEthernet, actually.. this was a 2621.)
> >
> > I was playing with an FTP client on the 192.168.0.2 machine, watching the
> > translation tables with the sho ip nat trans command.  I was trying to see
> > if I could get the Cisco to open arbitrary holes to other hosts by sending
> > manual PORT commands.  I didn't get that to work, but I found a cute little
> > problem.
> >
> > At the time, I was telnetted to the router from the outside, which is how I
> > was watching the translations table.  From the inside, I issued the command
> > PORT 192,168,0,2,0,23 (I was listening on port 23 with netcat).
> >
> > My telnet session to the outside died.
> >
> > I was a bit puzzled.  I telnetted back right away, and that worked.  I
> > repeated the test a few times to convince myself it was doing what I
> > thought it was.  Whenever I issues that PORT command, my telnet connection
> > died.
> >
> > I have to assume that since the NAT config I used uses the router's own
> > (outside) IP address that the NAT is interfering with the router's own
> > listening ports.  Make me wonder what else could be done with this...
> >
> >                                                                BB

Despite the late response, we _have_ been working on this problem.  We
have confirmed the behavior as documented by Blue Boar.  The section of
code responsible for the behavior has been identified and a fix is in
development.  We have considered workarounds, but have not yet defined any
that are suitable for public dissemination and discussion.

Because of the amount of time that has passed, we (the Cisco Product
Security Incident Response Team and other Cisco Customer Advocacy staff)
felt that a status report and acknowledgement were necessary even though
we do not have a fix ready for distribution at this time.  As soon as we
have something else useful to say, we will post a follow-up message.  In
the meantime, sending messages to us asking about this problem will very
likely slow down our efforts to produce a remedy.

As always, we ask that you send notices of security vulnerabilities in any
Cisco product to the Cisco PSIRT at <psirt () cisco com>.  Advance notice
would be nice, but is not required -- any notice is preferred over the
risk of not hearing about the problem at all, including incomplete schemes
that may or may not constitute actual product vulnerabilities.  More PSIRT
information is available at the URL in my signature block below.

The messages and events that have lead up to this response have generated
a lot of thoughtful discussion internal to the team about how to improve
our handling of cases like this.  We are working on that, too, but we
won't be posting a security advisory about it.  Instead, we hope that you
will notice improvements over time.  This message is one such attempt.

Thanks.

        Jim


--
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
<http://www.cisco.com/warp/public/707/sec_incident_response.shtml>
E-mail: <jnduncan () cisco com>  Phone(Direct/FAX): +1 919 392 6209