More information regarding Etherleak

["Ofir Arkin" <ofir () sys-security com>]

This e-mail's purpose is to clear several issues surrounding the
Etherleak paper:

- Who is Vulnerable?
- Why this vulnerability is so wide spread?
- Why the examples are only with Linux device drivers?
- Why we have contacted CERT?
- Are Device Drivers under Microsoft-based OSs are vulnerable?
- How can you test your network card and device driver?
- Why is this better then a sniffer?
- Why the vulnerability is important?


Who is vulnerable?
------------------
Josh Anderson and I tested several Ethernet cards and device drivers.

We have found several device drivers which are vulnerable but we never
attempted to find them all. It is simply because there are too many.
Therefore we have contacted CERT more than 6 months ago and sent them
the Etherleak paper and asked them to contact OS manufactures, Network
device manufactures, Chipset manufactures, motherboard manufactures and
other manufactures and vendors who might need to check their device
driver's implementations.

In our tests we have experienced this bug under 4 different operating
systems:

- Linux
- NetBSD
- FreeBSD
- Microsoft Windows


One of the Ethernet cards and device drivers we have tested was a Compaq
PCMCIA Ethernet card under Windows 2000 (with the latest SP at the time)
which demonstrated the vulnerability (among other Ethernet cards which
have demonstrated the vulnerability under Microsoft Windows 2000).

It is clear to us that device drivers under the various Microsoft
operating systems are vulnerable.

Microsoft's statement to CERT:
"Microsoft does not ship any drivers that contain the vulnerability.
However, we have found samples in our documentation that, when compiled
without alteration, could yield a driver that could contain this issue.
We have made corrections to the samples in our documentation, and will
include tests for this issue in our certification process."

If you read the statement carefully you can understand that there are
OTHER manufactures which have built device drivers for their networking
equipment that are based on Microsoft's documentation and therefore
MIGHT BE VULNERABLE.

Microsoft does not make vulnerable device drivers BUT Microsoft's sample
code was vulnerable and therefore Microsoft has added a test to the
device driver's certification test which will test for the bug. The
situation is that CURRENT Microsoft certified device drivers MIGHT BE
VULNERABLE.


Different vendors were contacted by CERT more than 6 months ago and had
an enormous amount of time to fix this issue before it went public. The
authors did not receive a list of vendors who were notified by CERT. The
authors were aware that Microsoft was one of the vendors who were
contacted and notified regarding this vulnerability.

The examples in the paper are given from the Linux operating system
because it helps to illustrate the problem.


Why this vulnerability is so wide spread?
-----------------------------------------
Some networking gear manufactures choose to purchase (in some cases)
chipsets from a chipset manufacture rather then developing their own (or
using their own). Therefore you might find networking cards from one
vendor with chipsets of another chipset manufacture (for example some
low-end SMC cards are using RealTek chipsets). Some other manufactures
are embedding networking cards with their products (such as motherboards
with LAN). To minimize the cost, sometimes, low-end chipsets, which many
of whom have vulnerable device drivers on different operating system,
are used (some vulnerable device drivers are even shipped with some
cards...).


How can you test your network card and device driver?
-----------------------------------------------------
You need to send packets which are less than 46 data bytes long (the
minimum packet size) to examine if you experience this vulnerability
with your Ethernet card and device driver. Any packet less than 46 data
bytes long would do the trick but we have found the following examples
helpful:

- An ICMP Echo request packet with 1 data byte in its payload (total of
29 
  bytes). The rest - 17 data bytes will be filled with information (you
can  
  see for yourself in the paper we have written what kind of information
it 
  will be) if your Ethernet card's device driver is vulnerable.

- You can also use Raw Packets and then have 28 data bytes as room for 
  padded data.


Why is this better then a sniffer? or Why is this bug important?
----------------------------------------------------------------
First Example: 
You can extract information that you will never be able to see on a
switched environment. 

A Second Exmaple:
In some cases you will be able to extract information directly from a
Router on your LAN (try this with a Linux or a NetBSD machine acting as
a router with vulnerable Ethernet cards (and their device drivers) and
see for yourself how easily information is being gleaned) or from
another networking equipment on your LAN.

A Third Example:
Another example might be a corporate network (just think about the
scenario of a nice flat switched network).


There are special instances were the padded information might cross
layer 2 boundaries, but they are very unique in nature and depend on
many factors.

Combining the information is not a trivial task for script kiddies. If
you are experienced with networking and seen and analyzed network
traffic in the past you will be able to understand what are the portions
of information you are absorbing (see the examples in the paper).

In our tests we were able to extract pop3 passwords, other clear text
passwords, cookies, and other interesting pieces of information.


We hope this email will help the community and more people to understand
why this bug class is important and problematic.


We urge people to read the paper before they cry wolf...


Yours,
Ofir Arkin [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA