> -----Original Message-----
> From: FX [mailto:fx@xxxxxxxxxxxx]
> Sent: Wednesday, September 06, 2006 8:34 PM
> To: full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
> Subject: Cisco IOS GRE issue
>
> Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +---->
>
> [ Title ]
> Cisco Systems IOS GRE decapsulation fault
>
> [ Authors ]
> FX <fx@xxxxxxxxxxxx>
>
> Phenoelit Group ()
> Advisory
>
> [ 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@xxxxxxxxx
> 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@xxxxxxxx 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@xxxxxxxxxxxx>
> Phenoelit ()
> 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564
>
