-----BEGIN PGP SIGNED MESSAGE----- =============================================================================== Security Advisory CERT-NL =============================================================================== Author/Source : Teun Nijssen Index : S-98-81 Distribution : World Page : 1 Classification: External Version: 1 Subject : Cisco IOS 12.0 UDP syslog port Date : 22-Dec-98 =============================================================================== By courtesy of John Bashinski, the Security Czar of Cisco Systems, we received information on a vulnerability in IOS 12.0 CERT-NL recommends to block incoming syslog traffic for routers own addresses immediately. ============================================================================== John writes: We've had a report of nmap UDP scans crashing Cisco routers running Cisco IOS software version 12.0. This was apparently mentioned on BUGTRAQ, although the BUGTRAQ message has not yet arrived at Cisco. We've verifed 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.). We do *not* think that it affects any non-12.0 version. However, we got the bug report only three hours ago, have not yet finished characterizing it, and can't yet be completely sure which versions or which platforms are affected. This is very easy to exploit, and has now been announced very widely. Administrators should be on the lookout for it. 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: access-list 101 deny udp any host eq 514 access-list 101 deny udp any host eq 514 access-list 101 deny udp any host eq 514 ... etc ... access-list 101 permit ip any any interface ip access-group 101 in interface ip access-group 101 in ... etc ... The access list needs to block syslog traffic destined for any of the router's own IP addresses. 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 only partially characterized, 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 ============================================================================== 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 eq 514 access-list 101 deny udp any host eq 514 access-list 101 deny udp any host eq 514 ... etc ... access-list 101 permit ip any any interface ip access-group 101 in interface 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/public/791/sec_incident_response.shtml -- J. Bashinski Cisco Systems ============================================================================== CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet is the Dutch network for educational, research and related institutes. CERT-NL is a member of the Forum of Incident Response and Security Teams (FIRST). All CERT-NL material is available under: http://www.surfnet.nl/surfnet/security/cert-nl.html ftp://ftp.surfnet.nl/surfnet/net-security In case of computer or network security problems please contact your local CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer please address the appropriate (local) CERT/security-team). CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer, i.e. UTC+0100 in winter and UTC+0200 in summer (DST). Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS Phone: +31 302 305 305 BUSINESS HOURS ONLY Fax: +31 302 305 329 BUSINESS HOURS ONLY Snailmail: SURFnet bv Attn. CERT-NL P.O. Box 19035 NL - 3501 DA UTRECHT The Netherlands NOODGEVALLEN: 06 52 87 92 82 ALTIJD BEREIKBAAR EMERGENCIES : +31 6 52 87 92 82 ATTENDED AT ALL TIMES CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES: THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED* PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU. ============================================================================== -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.5.3i for non-commercial use iQCVAwUBNoCW6FpSTqmIRWKVAQGxXwP9E0IFY460W+Nr22sykPjUakMgdg2QRTYx l8fw6dL5OpyaM8gNf/OT05nlYVxig1kseLFJXrI1pjhHUaf/8eLbgViBMSifikn1 G9GpCM+popDpscF60b9WmOQc2hWbZNQoVyAZaXcM3bR8fvjYCbWyLOYR+6iENhIG JPoq4OhHX9U= =QHOn -----END PGP SIGNATURE-----