Search This Blog

Wednesday, July 25, 2007

[NEWS] Cisco Wireless ARP Storm Vulnerabilities

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html


- - - - - - - - -

Cisco Wireless ARP Storm Vulnerabilities
------------------------------------------------------------------------


SUMMARY

Cisco Wireless LAN Controllers (WLC) contain multiple vulnerabilities in
the handling of Address Resolution Protocol (ARP) packets that could
result in a denial of service (DoS) in certain environments.

Cisco is notifying customers and partners and has made free software
available to address these vulnerabilities for affected customers. There
are workarounds available to mitigate the effects of these
vulnerabilities.

DETAILS

Affected Products
Unless otherwise specified, the vulnerabilities addressed in this document
affect versions 4.1, 4.0, 3.2, and prior versions of the Wireless LAN
Controller software. To identify the earliest software releases that
include fixes for these vulnerabilities, please consult the Software
Versions and Fixes section of this advisory.

To determine the version of WLC system software running on a particular
device, one of the following methods may be used:
* In the web interface, choose the Monitor tab, click Summary in the
left-hand pane, and note the "Software Version."
* From the command-line interface, type show sysinfo and note the
"Product Version."

Vulnerable Products
Vulnerable versions of software may be running on any of the following
hardware platforms:
* Cisco 4100 Series Wireless LAN Controllers
* Cisco 4400 Series Wireless LAN Controllers
* Cisco Airespace 4000 Series Wireless LAN Controller
* Cisco Catalyst 6500 Series Wireless Services Module (WiSM)
* Cisco Catalyst 3750 Series Integrated Wireless LAN Controllers

Products Confirmed Not Vulnerable
The following hardware platforms are not affected by these
vulnerabilities:
* Cisco 2000 Series Wireless LAN Controllers
* Cisco 2100 Series Wireless LAN Controllers
* Cisco Airespace 3500 Series WLAN Controller
* Cisco 526 Wireless Express Mobility Controller
* Cisco Wireless LAN Controller Module
(NM-AIR-WLC6-K9,NME-AIR-WLC8-K9,NME-AIR-WLC12-K9)
* Standalone Access Points such as the 1100 Series, 1200 Series and
AP340/350
* Cisco 3800 Series Integrated Services Routers
* Cisco 2800 Series Integrated Services Routers
* Cisco 1800 Series Integrated Services Routers
* Cisco 800 Series Routers

Details
Cisco Wireless LAN Controllers provide real-time communication between
lightweight access points and other Wireless LAN controllers for
centralized system wide WLAN configuration and management functions.

The Address Resolution Protocol, or ARP, provides a mapping between a
device's IP address and its hardware address on the local network.

The WLC contains vulnerabilities in the processing of unicast ARP traffic
where a unicast ARP request may be flooded on the LAN links between
Wireless LAN Controllers in a mobility group.

<http://www.ietf.org/rfc/rfc4436.txt> RFC4436 defines a method for IP
Version 4 hosts to detect if they have re-attached to a previously
attached network. In such cases, it may be unnecessary to request a new
DHCP address lease if the current lease is still active. To determine
reattachment, the host may send a unicast ARP request to the address of
the default gateway that it had previously used.

A vulnerable WLC may mishandle unicast ARP requests from a wireless client
leading to an ARP storm. In order for the vulnerability to be exposed, two
WLCs attached to the same set of Layer-2 VLANs must each have a context
for the wireless client. This can occur after a Layer-3 (cross-subnet)
roam or when guest WLAN (auto-anchor) is in use.

If the client sends a unicast ARP request with a destination MAC address
that has not been learned by the Layer-2 infrastructure, that request will
be flooded to all ports in the Layer-2 domain after egressing the WLC.
This allows the second WLC to reprocess the ARP request and incorrectly
reforward this packet back into the network. This vulnerability is
documented as
<http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj69233> CSCsj69233 ( registered customers only) .

If the arpunicast feature has been enabled on the WLC, the WLC will
re-forward broadcast ARP packets targeting the IP address of a known
client context. This creates an ARP storm if more than one WLC is
installed on the corresponding VLAN. This vulnerability is documented as
<http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj70841> CSCsj50374 ( registered customers only) and only affects version 4.1 of the WLC software (versions 4.0, 3.2, or previous versions are not affected).

In a Layer-3 (L3) roaming scenario, a wireless client moves from one
controller to another where the wireless LAN interfaces configured on
different controllers are on different IP subnets. In this scenario, a
unicast ARP may not tunneled back to the anchor controller, but may
instead be sent by the foreign controller out to a local VLAN. This
vulnerability is documented as
<http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj70841> CSCsj70841 ( registered customers only) .

Note: In versions of software prior to 4.1, a unicast ARP request from a
wireless client that performed a Layer-3 roam was dropped at the Foreign
WLC. This behavior has been corrected as part of
<http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj70841> CSCsj70841 ( registered customers only) .

Impact
Successful exploitation of these vulnerabilities may result in a DoS
condition.

Workarounds
For enhanced security, Cisco recommends that operators require all clients
to obtain their IP addresses from a DHCP server. To enforce this
requirement, all WLANs can be configured with a DHCP Required setting,
which disallows client static IP addresses. If DHCP Required is selected,
clients must obtain an IP address via DHCP. Any client with a static IP
address will not be allowed on the network. The controller monitors DHCP
traffic because it acts as a DHCP proxy for the clients.

This workaround is generally effective for wireless clients employing the
mechanisms defined in <http://www.ietf.org/rfc/rfc4436.txt> RFC4436 when
joining a network. It is not effective against deliberate attempts to
craft packets that create an ARP storm.

Customers experiencing exploitation from the vulnerability associated with

<http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj50374> CSCsj50374 ( registered customers only) may configure the WLC to disable arpunicast processing via the CLI:

config network arpunicast disable

This section provides both GUI and CLI instructions for configuring your
WLAN to use a DHCP server.

Using the GUI to Configure DHCP
1. In the web user interface, navigate to the WLANs page.
2. Locate the WLAN you wish to configure for a DHCP server, and click the
associated Edit link to display the WLANs > Edit page.
3. Under General Policies, check the DHCP Relay/DHCP Server IP Addr check
box to verify whether you have a valid DHCP server assigned to the WLAN.
If you do not have a DHCP server assigned to the WLAN, continue with Step
4. Otherwise, continue with Step 9.
4. Under General Policies, uncheck the Admin Status check box.
5. Click Apply to disable the WLAN.
6. In the DHCP Relay/DHCP Server IP Addr edit box, enter a valid DHCP
server IP address for this WLAN.
7. Under General Policies, check the Admin Status check box.
8. Click Apply to assign the DHCP server to the WLAN and to enable the
WLAN. You are then returned to the WLANs page.
9. In the upper-right corner of the WLANs page, click Ping and enter the
DHCP server IP address to verify that the WLAN can communicate with the
DHCP server.

Using the CLI to Configure DHCP
1. In the CLI, enter show wlan to verify whether you have a valid DHCP
server assigned to the WLAN. If you do not have a DHCP server assigned to
the WLAN, continue with Step 2. Otherwise, continue with Step 4.
2. If necessary, use the following commands:
config wlan disable <wlan-id>
config wlan dhcp_server <wlan-id> <dhcp-server-ip-address>
config wlan enable <wlan-id>

In these commands, wlan-id = 1 through 16, and dhcp-server-ip-address =
DHCP server IP address.
3. Enter show wlan to verify that you have a DHCP server assigned to the
WLAN.
4. Enter ping dhcp-ip-address to verify that the WLAN can communicate with
the DHCP server.


ADDITIONAL INFORMATION

The information has been provided by <mailto:psirt@cisco.com> Cisco
Systems Product Security Incident Response Team.
The original article can be found at:
<http://www.cisco.com/warp/public/707/cisco-sa-20070724-arp.shtml>

http://www.cisco.com/warp/public/707/cisco-sa-20070724-arp.shtml

========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

No comments: