Attack Surface
Device drivers suffer from the same types of vulnerabilities that apply to any
other code written in the C programming language. Buffer mismanagement, faulty
pointer math, and integer overflows can all lead to exploitable conditions.
Device driver flaws are often seen as a low risk issue due to the fact that
most drivers do not process attacker-controlled data. The exception, of
course, are drivers for networking devices. Although Ethernet devices (and
their drivers) have been around forever, the simplicity of what the driver has
to handle has greatly limited the attack surface. Wireless drivers are
required to handle a wider range of requests and are also required to expose
this functionality to anyone within range of the wireless device.
In the world of 802.11 device drivers, the attack surface changes based
on the state of the device. The three primary states are:
- Unauthenticated and Unassociated
- Authenticated and Unassociated
- Authenticated and Associated
In the first state, the client is not connected to a specific wireless
network. This is the default state for 802.11 drivers and will be the focus
for this section. The 802.11 protocol defines three different types of frames:
Control, Management, and Data. These frame types are further divided into
three classes (1, 2, and 3). Only frames in the first class are processed in
the Unauthenticated and Unassociated state.
The following 802.11 management sub-types are processed by clients while in state 1[3]:
- Probe Request
- Probe Reponse
- Beacon
- Authentication
The Probe Response and Beacon sub-types are used by wireless devices to
discover and advertise the local wireless networks. Clients can transmit Probe
Responses to discover networks as well (more below). The Authentication
sub-type is used to join a specific wireless network and reach the second
state.
Wireless clients discover the list of available networks in two different
ways. In Active Mode, the client will send a Probe Request containing an
empty SSID field. Any access point in range will reply with a Probe Response
containing the parameters of the wireless network it serves. Alternatively,
the client can specify the SSID it is looking for. In Passive Mode, clients
will listen for Beacon requests and read the network parameters from within
the beacon. Since both of these methods result in a frame that contains
wireless network information, it makes sense for the frame format to be
similar. The method chosen by the client is determined by the capabilities of
the device and the application using the driver.
A beacon frame includes a generic 802.11 header that defines the packet type,
source, destination, Basic Service Set ID (BSSID) and other envelope
information. Beacons also include a fixed-length header that is composed of a
timestamp, beacon interval, and a capabilities field. The fixed-length header
is followed by one or more Information Elements (IEs) which are
variable-length fields and contain the bulk of the access point information.
A probe response frame is almost identical to a beacon frame except that the
destination address is set to that of the client whereas beacons set it to the
broadcast address.
Information elements consist of an 8-bit type field, an 8-bit length field,
and up to 255 bytes of data. This type of structure is very similar to the
common Type-Length-Value (TLV) form used in many different protocols.
Beacon and probe response packets must contain an SSID IE, a Supported Rates
IE, and a Channel IE for most wireless clients to process the packet.
The 802.11 specification states that the SSID field (the human name for a
given wireless network) should be no more than 32 bytes long. However, the
maximum length of an information element is 255 bytes long. This leaves quite
a bit of room for error in a poorly-written wireless driver. Wireless drivers
support a large number of different information element types. The standard
even includes support for proprietary, vendor-specific IEs.
|