[11193] in bugtraq
Re: CaseID T70813: Re-open case T70813
daemon@ATHENA.MIT.EDU (tac@CISCO.COM)
Fri Jul 30 15:16:35 1999
Message-Id: <199907291032.GAA21720@runamuk.cisco.com>
Date: Thu, 29 Jul 1999 06:32:28 -0400
Reply-To: tac@cisco.com
From: tac@CISCO.COM
X-To: BUGTRAQ@NETSPACE.ORG
To: BUGTRAQ@SECURITYFOCUS.COM
Johnny,
As per your request i reopened case T70813.
The next available engineer will contact you shortly.
Best Regards,
--
Emiliano Citarella
Customer Response Center
Technical Assistance Center
Cisco Systems
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_000_01BED9A8.54EC76CE
> Content-Type: text/plain
>
> CONTRACT #: 10066002
> SERIAL#: 066549046
> PRODUCT TYPE:
> EQUIPMENT LOCATION: Customer
> COMPANY NAME: Cable & Wireless HKT
> SITE NAME: HONGKONG TELECOM CSL
> PICA I.D.: nil
> COMPANY ADDRESS: 1/F Hongkong Telecom Building 43 Sheung Shing Street HO MAN
> TIN, Kowloon Hong Kong
> SITE ADDRESS: nil
> CONTACT: Johnny Leung
> SITE CONTACT: nil
> PHONE: (852) 2760-2232
> SITE PHONE:
> FAX #: (852) 2714-7663
> SITE EMAIL: nil
> PAGER: nil
> MOBILE #: nil
> EMAIL: johnny.mp.leung@cwhkt.com
>
> I received a query from our customer and he attached the following email and
> asked is the bug CSCdk77426 affect IOS ver rsp-jsv-mz_112-17_P also? If it
> does, will that be possible the casue of this case? Plz advise.
> <<CISCO-IO.TXT>>
>
> ------_=_NextPart_000_01BED9A8.54EC76CE
> Content-Type: text/plain;
> name="CISCO-IO.TXT"
> Content-Disposition: attachment;
> filename="CISCO-IO.TXT"
> Content-Transfer-Encoding: quoted-printable
>
> Date: Tue, 22 Dec 1998 14:41:44 -0800
> From: Jason Ackley <jason@ACKLEY.NET>
> Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
> To: BUGTRAQ@netspace.org
> Subject: Re: Cisco IOS 12.0 security bug and workaround
>
> On Tue, 22 Dec 1998, John Bashinski wrote:
>
> > characterizing it, and can't yet be completely sure which versions
> > or which platforms are affected.
>
> Crashes:
> IOS (tm) 4000 Software (C4000-IK2S-M), Version 12.0(2)T
> (this is an old 68030 based 4000)
>
> IOS (tm) 2500 Software (C2500-IOS56I-L), Version 12.0(2)
> (this is a 2514)
>
> > This bug may cause different router platforms to crash differently.
> > Some routers have been observed to reboot and claim that they
> > were "restarted by power-on"; you won't necessarily get a stack
> > trace from one of these crashes.
>
> C4000 crashed with :
> System restarted by address error at PC 0x10006E8, address 0x802320
>
> C2500 crashes with:
> System restarted by error - Illegal Instruction, PC 0x0
>
> The 2514 seemed to take a bit longer to crash than the 4000, which was
> almost instant death.. Maybe it was just me..
>
> I also noticed that the 4000 at least still is listening on the bootp
> server port, even tho I have 'no ip bootp server' set.. bug or feature?
>
> Cheers,
>
> --
> Jason Ackley jason@ackley.net
>
> -----------------------------------------------------------------------
>
> Date: Tue, 22 Dec 1998 13:39:30 -0800
> From: John Bashinski <jbash@CISCO.COM>
> Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
> To: BUGTRAQ@netspace.org
> Subject: Update on Cisco IOS 12.0 security bug
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> This is an update for a message I sent about 5 hours ago.
>
> Changes from the earlier message:
>
> 1. We've found more affected versions. In addition to all 12.0 =
> variants,
> 11.3AA and 11.3DB are affected. Plain old 11.3 is *not* affected.
> Neither is, 11.3T, or any of the other 11.3 variants we've
> looked at. We now know where the bug was introduced, and it's
> unlikely that that code has made its way into any releases other
> than 11.3AA, 11.3DB, and the 12.0 variants. When our Sydney office
> wakes up, we'll be able to make some final checks.
>
> 2. I left out the bug ID in the last message. It's CSCdk77426.
>
> 3. The workaround text mentions broadcast addresses.
>
> We still don't have fix dates; it can take some time to get fixes
> through the release process. When we have fix dates, we'll do
> a formal notice.
>
> Amended message follows--
>
> We've had a report of nmap UDP scans crashing Cisco routers running
> Cisco IOS software version 12.0. This was mentioned on BUGTRAQ, which
> has a very wide distribution. It would be very easy to exploit.
> Administrators should be on the lookout for potential exploitation of
> this bug.
>
> We've verified that the problem does exist. We believe that it affects
> all Cisco routers running any variant of 12.0 (including 12.0T, 12.0S,
> etc.). 11.3AA and 11.3DB are also affected. Mainline 11.3 and 11.3T are
> not affected. None of the other 11.3 variants that we've checked are
> affected. Because of where the problem was introduced, we think that
> 11.3AA and 11.3DB are almost certainly the only affected 11.3
> variants. We will continue to check other 11.3 variants, and will issue
> another update if any turn up affected.
>
> The problem appears to be caused by packets sent to the router's syslog
> port (UDP port 514). A tested workaround is to use an access list to
> block incoming syslog traffic. You'd do this with something like this:
>
> ! Deny all multicasts to port 514
> access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514
> ! Deny old-style broadcasts
> access-list 101 deny udp any host 0.0.0.0 eq 514
> ! Deny network-specific broadcasts (*example*; depends on local =
> netmasks)
> access-list 101 deny udp any 192.31.7.255 eq 514
> ! Deny router's own addresses
> access-list 101 deny udp any host <router-addr-1> eq 514
> access-list 101 deny udp any host <router-addr-2> eq 514
> access-list 101 deny udp any host <router-addr-3> eq 514
> ... etc ...
> access-list 101 permit ip any any
>
> interface <interface-1>
> ip access-group 101 in
>
> interface <interface-2>
> ip access-group 101 in
>
> ... etc ...
>
> The access list needs to block syslog traffic destined for any of the
> router's own IP addresses, or for any broadcast or multicast address on
> which the router may be listening. Don't forget to block all-zeroes
> broadcasts as well as all-ones broadcasts. It should be applied on
> all interfaces running IP, including virtual interfaces and
> subinterfaces (but not loopback interfaces).
>
> This workaround *does* have a performance impact that may be =
> significant
> for some users. The impact isn't usually extreme, but it may make a
> difference on a router that's already heavily loaded. Install it with
> care if you install it.
>
> This bug may cause different router platforms to crash differently.
> Some routers have been observed to reboot and claim that they
> were "restarted by power-on"; you won't necessarily get a stack
> trace from one of these crashes.
>
> Since this is still not completely characterized, and since we do not
> yet have any reports of exploitation, you may choose to hold the
> workaround in reserve and apply it only if you believe you are being
> attacked. We should have a formal notice with full details within the
> next few days. We cannot yet make any estimate of when a fix will be
> available; we should have more information by the time the formal =
> notice
> comes out.
>
> If you find that you are actually attacked with this, please report
> the attack to Cisco at "security-alert@cisco.com".
>
> For more information on Cisco security procedures, see
>
> http://www.cisco.com/warp/customer/791/sec_incident_response.shtml
>
> -- J. Bashinski
> Cisco Systems
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3in
> Charset: noconv
>
> iQEVAwUBNoARckZi51ggEbh5AQEVlwf9EKP5iPzwfp4UpxsN1nnqLscyrLYYKXIs
> ce/EMcQP7znbkmse6cSFz5nOIKQpRl+c+rxLg8V3oeGTEriIyOA/jR0oVeU2Nn4N
> rS6daaorZU1ngGhZ4zTRYNoGbGOU4EjwnU/wJV1yrrIuLA3EAHz+67kT90qSRJy7
> R8ny+0tbtu7ZFdHI9Ccokal59HOz+Gbt29ep5/Ft0REVFoRqJCphJP06bT2HLIXZ
> qLXPBErmVc9fP0wqdf11tbc3zaiytBbVn6is9sFdqod14KeiBblOC99vfM7OG1KY
> rh3pLqSeLs76sw4RZycXAQWdLiY3Xgx3ZFwhB0YrpzUJnXGEDbcb7Q=3D=3D
> =3DXp1o
> -----END PGP SIGNATURE-----
>
>
>
> ------_=_NextPart_000_01BED9A8.54EC76CE--
>
