[scg-sec] (fwd) Re: Telnet Vulnerability

[Wendy Garvin]

Folks,

There's a corner case where a valid telnet connection could cause a problem,
details at the bottom of this message. Clay's included some valuable info on
identifying an attack case and the source.

----- Forwarded message from Clayton Kossmeyer <ckossmey at cisco.com> -----

Date: Fri, 27 Aug 2004 12:39:38 -0400
From: Clayton Kossmeyer <ckossmey at cisco.com>
To: Wendy Garvin <wgarvin at cisco.com>
Cc: Jason Gardiner <gardiner at sprint.net>, ckossmey at cisco.com
Subject: Re: Telnet Vulnerability


Hi Wendy, Jason -

I'd agree with Wendy on this one, from the information in the case, it
looks to me like it's plausible that the telnet session that triggered
the lockout.

One thing that won't be mentioned in the advisory yet is how to
identify if the window size has gone to 0.

If you suspect monkey-business you can (somewhat) quickly check with
'sh tcp | include sndwnd':

ck-gw#sh tcp | inc sndwnd
iss: 1454838581  snduna: 1455145990  sndnxt: 1455145990     sndwnd:   1400
iss:  822512864  snduna:  822513018  sndnxt:  822513020     sndwnd:  34000
iss: 1324988810  snduna: 1324998274  sndnxt: 1324998274     sndwnd:  34000
iss:  651876200  snduna:  651881526  sndnxt:  651881526     sndwnd:  58480

If you see a 'sndwnd' field that's gone to 0 (or something oddly low,
as Wendy mentions below), that could be your culprit.  Iterating
through 'sh tcp vty <x> | inc sndwnd' will tell you which connection
is causing the problem.  'clear tcp line vty <x>' will disconnect it.

Clay

On Fri, Aug 27, 2004 at 09:02:49AM -0700, Wendy Garvin wrote:
> 
> Thanks Jason,
> 
> It looks like the same thing. There's a corner case which we didn't mention
> in the advisory in which you can be telnetted into the router from a small
> segment size (MSS < 1/4 of the destination router MSS) - if the router is
> under a dos attack or is spiking CPU for another reason, and that telnet
> connection is lost, and the window size is permanently stuck at less than
> 1/4 of the destination router MSS, and the router is busy with other things
> and doesn't change state on the connection to note that it's dropped.
> 
> That's normally hard to trigger, because a proper telnet session will change
> in window size, and the recipient telnet process will note that change, so
> it won't get stuck. Under most circumstances the router will see that
> the session has dropped and reset the connection. It's only in combination
> with another high cpu or low memory event that we may see this corner case.
> 
> So I'd be hesitant to guess that your router came under attack with this
> vulnerability, I think it's more likely it was a rare combination of events.
> I've copied Clay on this as well so he can hop in with an opinion if he'd
> like.
> 
> -Wendy

----- End forwarded message -----

-- 
Wendy Garvin - Cisco PSIRT - 408 525-1888 CCIE# 6526
----------------------------------------------------
           http://www.cisco.com/go/psirt