Cisco IOS GRE issue (fwd)

6 Sep 2006


      ---------- Forwarded message ----------
Date: Wed, 6 Sep 2006 18:33:44 +0200
From: FX <fx@phenoelit.de>
To: full-disclosure@lists.grok.org.uk, bugtraq@securityfocus.com
Subject: Cisco IOS GRE issue

Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +---->

[ Title ]
        Cisco Systems IOS GRE decapsulation fault

[ Authors ]
        FX              <fx@phenoelit.de>

        Phenoelit Group (http://www.phenoelit.de)
        Advisory        http://www.phenoelit.de/stuff/CiscoGRE.txt

[ Affected Products ]
        Cisco IOS 

        Tested on:      C3550 IOS 12.1(19)

        Cisco Bug ID:   CSCuk27655, CSCea22552, CSCei62762
        CERT Vu ID:     <not assinged>

[ Vendor communication ]
        07.07.05        Initial Notification, gaus@cisco.com
        27.07.05        PSIRT realized that nobody took this bug, Paul Oxman
                        took over
        28.07.05        Paul successfully reproduces the issue
        04.08.05        Paul notifies FX about availabe fixes
        05.08.05        Paul notifies FX about new side effects discovered
                        by Cisco
        06.09.06        Final advisory going public as coordinated release
                        *Note-Initial notification by phenoelit
                        includes a cc to cert@cert.org by default

[ Overview ]
        Cisco Systems IOS contains a bug when parsing GRE packets
        with GRE source routing information. A specially crafter GRE packet
        can cause the router to reuse packet packet data from unrelated 
        ring buffer memory. The resulting packet is reinjected in the routing
        queues.

[ Description ]
        The GRE protocol according to RFC1701 supports source routing
        different from the one known in IPv4. An optional header is added to
        the GRE header containing Source Route Entries for further routing.
        
        GRE header:
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |C|R|K|S|s|Recur|  Flags  | Ver |         Protocol Type         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Checksum (optional)      |       Offset (optional)       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Key (optional)                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Sequence Number (optional)                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Routing (optional)                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        When a specially crafted GRE packet with routing information is 
        received by a Cisco IOS device, the offset field is not verified
        to point inside the packet but is subtracted from what appears 
        to be a short integer holding the overall length of the IP packet,
        causing an overflow of the same.

        This causes other memory contents of the packet ring buffers to
        be interpreted as the payload IP packet and reinjected into the
        routing queue with fairly large length information:

        GRE decapsulated IP 0.3.74.0->0.0.1.30 (len=65407, ttl=39)
        GRE decapsulated IP 176.94.8.0->0.0.0.0 (len=64904, ttl=0)
        GRE decapsulated IP 0.15.31.193->176.94.8.0 (len=64894, ttl=237)
        GRE decapsulated IP 128.42.131.220->128.0.3.74 (len=64884, ttl=128)

        The outer IP packet must come from the configured tunnel source
        and be sent to the configured tunnel destination IP address.

        By carefully filling the ring buffers with legitimate traffic like
        ICMP, containing an IP header at the right offset, an attacker can
        create IP packets with large length values inside IOS. PSIRT 
        believes this cannot be done, Phenoelit differs on that.

[ Example ]
        Internet Protocol, 
                Src Addr: 85.158.1.110 (85.158.1.110), 
                Dst Addr: 198.133.219.25 (198.133.219.25)
            Version: 4
            Header length: 20 bytes
            Differentiated Services Field: 0x00
            Total Length: 28
            Identification: 0xaffe (45054)
            Flags: 0x00
            Fragment offset: 0
            Time to live: 30
            Protocol: GRE (0x2f)
            Header checksum: 0xf409 (correct)
            Source: 85.158.1.110 (85.158.1.110)
            Destination: 198.133.219.25 (198.133.219.25)
        Generic Routing Encapsulation (IP)
            Flags and version: 0x4000
                0... .... .... .... = No checksum
                .1.. .... .... .... = Routing
                ..0. .... .... .... = No key
                ...0 .... .... .... = No sequence number
                .... 0... .... .... = No strict source route
                .... .000 .... .... = Recursion control: 0
                .... .... 0000 0... = Flags: 0
                .... .... .... .000 = Version: 0
            Protocol Type: IP (0x0800)
            Checksum: 0x0000
            Offset: 99

[ Notes ]
        IOS implements GRE source routing as forwarding of the inner IP
        packet. Thus, a Source Route Entry of 255.255.255.255 will cause
        IOS to resend the GRE packet to the specified address according
        to the routing table (all in this case) on the appropriate 
        interface (all in this case).
        The source address of the new packet will be the router's IP 
        address, the destination address according to the received packet.
        This can be used to circumvent Access Control Lists with GRE.

[ Solution ]
        Stop using GRE. There is no way in IOS to turn off source routing
        for GRE tunnels.

        To correct the parsing issue, try to install an IOS version
        containing the fixes CSCuk27655 or CSCea22552 or CSCei62762.

[ end of file ($Revision: 1.3 $) ]

-- 
         FX           <fx@phenoelit.de>
      Phenoelit   (http://www.phenoelit.de)
672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564

Gadi Evron

tags

participants (1)