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

[Wendy Garvin]

FYI - Watch for symptoms on all sorts of services - in the case the symptom
was on a non-responsive ssh session. Although the vuln. is in the telnet
service, the problem shows up all over the map.  VTY based connections
include telnet, reverse telnet, RSH, SSH, SCP and version 1.0 of the HTTP
server. 

Thanks,

-Wendy

> Wendy Garvin <wgarvin at cisco.com> [2004-08-27 12:18] wrote:
> 
> 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
> _______________________________________________
> scg-sec mailing list
> scg-sec at puck.nether.net
> https://puck.nether.net/mailman/listinfo/scg-sec
> 
> [    ----- End of Included Message -----    ]

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