Field Notice - IOS Accepts ICMP Redirects in Non-default Configuration Settings

[Damir Rajnovic <gaus () cisco com>]

-----BEGIN PGP SIGNED MESSAGE-----

=======================
Field Notice - IOS Accepts ICMP Redirects in Non-default
               Configuration Settings

 Field Notice Number 23074 
 Publish Date        2003-February-10
 Author              Damir Rajnovic <gaus () cisco com>


Products Affected

        Product                         Comments
     ------------------------------------------------------------------
      All Cisco IOS    This issue is not specific to any Cisco IOS 
      software         release or device configuration. The device is 
                       only vulnerable if IP routing is disabled. The 
                       IP routing is enabled by default and it must be 
                       explicitly disabled if required.  


Problem Description

     If a router has IP routing disabled it will accept bogus ICMP 
     redirect packets and modify its routing table accordingly. With 
     IP routing disabled, the router will act as a Host and it will 
     comply with the Host Requirements given in the RFC1122. If IP 
     routing is enabled(which it is by default) ICMP redirect packets 
     are received and recognized but ignored. The router will not update 
     its routing table with the information present in the redirect 
     packets.   

Background

     This vulnerability was reported to Cisco by Ofir Arkin while at 
     @stake (currently The Sys-Security Group, ofir () sys-security com).   

Problem Symptoms

     By sending bogus ICMP redirect packets a malicious user can either
     disrupt or intercept communication from a router. 

     The disruption can be accomplished by advertising that a default 
     gateway is an unused IP address from the local subnet. That will
     effectively prevent the router from sending any packets to any 
     destination that is outside the local subnet. 

     Another possibility is to advertise a gateway that is on the 
     completely different subnet. If there is a device that will proxy 
     ARP request for this bogus gateway, all victim's traffic destined 
     outside of the local subnet may be forwarded to the bogus gateway, 
     which would cause the victim's traffic to leak out of the local 
     subnet to a device of attacker's choosing. If there is no device 
     that will proxy ARP requests for a bogus gateway then the scenario
     collapses to the first scenario where traffic is simply blocked. 

     The last possibility is that malicious user inserts a default 
     gateway whose IP address is the address of the attacker's machine 
     itself. That way a malicious user will be able to receive all 
     victim's traffic host that is destined outside of the local subnet.
     That traffic can subsequently be recorded or manipulated at the 
     attackers' will. The traffic can even be forwarded to the correct 
     gateway so that the victim will be unable to notice what is going 
     on. That a malicious user could participate as a default gateway 
     and intercept and record legitimate traffic is normal operation, 
     and is based on availability principles, and is not dependent on 
     the vulnerability of accepting llegitimate ICMP messages.   

Workaround/Solution

     The workaround is to prevent the router from acting upon ICMP 
     redirect packets. This can be accomplished in the following manner:

     Router(config)#no ip icmp redirect

     The preferred way would be to upgrade to the fixed IOS release. 
     The first fixed releases are:

     12.2(13.03)B
     12.2(12.05)T
     12.2(12.05)S
     12.2(12.05)
     12.2(12.02)S
     12.2(12.02)T

     These releases are fixed as of the time this notice was written. 
     For the most current list of the fixed releases consult the DDTS
     CSCdx92043.

DDTS

         DDTS                           Description
      CSCdx92043                  IOS accepts wrong ICMP redirects

For More Information 


     Registered users (http://www.cisco.com/register) can view the 
     DDTS details.
     

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQEVAwUBPkfOkg/VLJ+budTTAQF0UQgAjQqkrs8ffnMiZECwV5AVe0GV9+7T5kAv
+o4fXrgLSp+5gEDmoOfO1uMr4z1lR9866OhzBCHCQwFD97Vu7JHAqTKpQ3HfDX2a
mbGVrkOEQn2YTNIq8yOt4s+CrdSNvNwRvkvw0cZXxqPeTED7ipiZU5DrVeKBq/5d
OEp3UJ5Wltq5kkdzNba5U/Oqv/grba71ks9GVPoLim5995iimPxDx8zQYkENPp4O
IrczzAaMvX7Pbda4qatftDAfjDR7kGGXrRBTUHlAT5YxR++o/7g1hqGCj+lqkTIW
Jze1+HzVYdmDUab7GLc+/87J9JQv5CmPuE22aYLmJ+HESpZ8CYXaVQ==
=AFOd
-----END PGP SIGNATURE----- 
==============
Damir Rajnovic <psirt () cisco com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution?