[scg-sec] Telnet Vulnerability

Thu Aug 26 23:40:41 EDT 2004

On Thu, 26 Aug 2004, Ryan McDowell wrote:

> I'd say its a non-issue, everybody should be running at least vty acl's
> and that is what console is for.
>

yes, everyone SHOULD be using vty acls... at
sprint/att/mci|uu/verio/C&W|Savvis/blah-large-nsp probably the use of vty
acls is 'standard' (not on our managed networks, because we suck, what
about yours?)

Many, many, many folks do NOT use vty acls :( reference Rob Thomas for
evidence of same :(

That being said, however, this doesn't affect 'me', and I'm not sure that
there is any great call for fire and brimstone (aside from cisco should
have not let a little coding error get them like this, oh well!) and Ryan
points out that Console (remote console) is quite effective at clearing
stuck lines, which is nice :)

> Although its interesting to see this as an explanation to why vty sessions lock
>  up.  We've opened up several cases on this and could never quite figure it
> out.  Any idea if other protocols are impacted?  We've had some problems with
> TCP/49 sessions getting stuck in CLOSEWAIT, maybe this is related somehow?
>
> Ryan McDowell
> NTAC Internet (SprintLink)
> Sprint Network Operations
> Office: +1 703 689 7527
> Mobile: +1 703 862 2570
> EED9 192F 9F45 FAE4 F6A3  8764 FEE1 299D 1B62 A361
>
> On Thu, 26 Aug 2004, Wendy Garvin wrote:
>
> >
> > Folks,
> >
> > The detail about the window size will be withheld from the initial advisory
> > in order to give customers time to implement the vty acl. Since we can't
> > write ACL's to block a connection based on the window size, there doesn't
> > seem to be any value in releasing this detail at first. At some point, we'll
> > want IDS vendors to be able to detect this and we'll release the details
> > then. The idea is to buy time. We may release this detail to the nsp-sec
> > list before we put it in the advisory.
> >
> > Thanks, and let me know if you think you see attempted exploitation. I wish
> > we could detect this with netflow. If any of you employ IDS systems and can
> > write custom signatures, we'd sure like to know if you get attacked.
> >
> > Paul - Can Junipers do ACLs based on window size?
> >
> > By the way, we're considering this an annoyance attack rather than a
> > production affecting attack, as it doesn't affect other TCP based protocols
> > like BGP or LDP. The worst we can see happening is that people are locked
> > out of managing their routers until they can get someone on site. While this
> > is not a good situation, at least the device is still routing and switching
> > traffic. We're also interested in knowing if that risk assessment misses
> > anything from your deployment point of view.
> >
> > Thanks,
> >
> > -Wendy
> >
> > > Battles, Timothy A (Tim), ALABS <tmbattles at att.com> [2004-08-26 11:51] wrote:
> > >
> > > Ohh, and clear line vty x
> > >
> > > Will not work.
> > >
> > > must be a clear tcp
> > >
> > > >-----Original Message-----
> > > >From: Jared Mauch [mailto:jared at puck.nether.net]
> > > >Sent: Thursday, August 26, 2004 1:43 PM
> > > >To: Battles, Timothy A (Tim), ALABS
> > > >Cc: scg-sec at puck.nether.net
> > > >Subject: Re: [scg-sec] Telnet Vulnerability
> > > >
> > > >
> > > >	so if there is a vty acl, we're safe, or semi-safe (ie:
> > > >hosts in the
> > > >acl only that can do 3-way).
> > > >
> > > >	- jared
> > > >
> > > >On Thu, Aug 26, 2004 at 02:39:19PM -0400, Battles, Timothy A
> > > >(Tim), ALABS wrote:
> > > >>
> > > >> Cisco Day1 VTY Vulnerability
> > > >>
> > > >> We have recently by accident discovered the following.
> > > >>
> > > >> After completing a 3-Way handshake with IOS and sending a
> > > >Window size of 0, the VTY handler becomes confused
> > > >> and will not allow other session to become established,
> > > >SYN-ACKS will be received from the router.
> > > >>
> > > >> In order to clear the session a
> > > >>
> > > >> clear tcp tcb xxxxxxxx
> > > >> clear tcp line x
> > > >> clear tcp line vty x
> > > >>
> > > >>
> > > >> needs to be issued.
> > > >>
> > > >>
> > > >> Some clarifiers
> > > >> This effects both telnet and ssh.
> > > >> The packet cannot be spoofed.
> > > >> This is IOS only. Day 1
> > > >>
> > > >>
> > > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > >> Timothy A Battles
> > > >> AT&T IP Network Security Group
> > > >> Work: (314)770-3326
> > > >> Cell: (314)280-4578
> > > >> Fax:  (314)770-9568
> > > >> Email: tmbattles at att.com
> > > >> 12976 Hollenberg Drive
> > > >> Bridgeton, MO 63044-2407
> > > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> scg-sec mailing list
> > > >> scg-sec at puck.nether.net
> > > >> https://puck.nether.net/mailman/listinfo/scg-sec
> > > >
> > > >--
> > > >Jared Mauch  | pgp key available via finger from jared at puck.nether.net
> > > >clue++;      | http://puck.nether.net/~jared/  My statements
> > > >are only mine.
> > > >
> > >
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > scg-sec mailing list
> > scg-sec at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/scg-sec
> >
>
> _______________________________________________
> scg-sec mailing list
> scg-sec at puck.nether.net
> https://puck.nether.net/mailman/listinfo/scg-sec
>