Re: CaseID T70813: Re-open case T70813

From: tacat_private
Date: Thu Jul 29 1999 - 03:32:28 PDT

  • Next message: Peter Boutzev: "Re: Redhat 6.0 cachemgr.cgi lameness"

    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.leungat_private
    >
    > 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 <jasonat_private>
    > Reply-To: Bugtraq List <BUGTRAQat_private>
    > To: BUGTRAQat_private
    > 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     jasonat_private
    >
    > -----------------------------------------------------------------------
    >
    > Date: Tue, 22 Dec 1998 13:39:30 -0800
    > From: John Bashinski <jbashat_private>
    > Reply-To: Bugtraq List <BUGTRAQat_private>
    > To: BUGTRAQat_private
    > 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-alertat_private".
    >
    > 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--
    >
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:12 PDT