cisco-ios12.txt

`Date: Tue, 22 Dec 1998 14:41:44 -0800  
From: Jason Ackley <[email protected]>  
Reply-To: Bugtraq List <[email protected]>  
To: [email protected]  
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 [email protected]  
  
-----------------------------------------------------------------------  
  
Date: Tue, 22 Dec 1998 13:39:30 -0800  
From: John Bashinski <[email protected]>  
Reply-To: Bugtraq List <[email protected]>  
To: [email protected]  
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 "[email protected]".  
  
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==  
=Xp1o  
-----END PGP SIGNATURE-----  
  
`