Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Ofir Arkin (ofir_at_sys-security.com)
Date: Fri Jan 10 2003 - 11:03:06 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

    - 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

    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

    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

    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

    - An ICMP Echo request packet with 1 data byte in its payload (total of
      bytes). The rest - 17 data bytes will be filled with information (you
      see for yourself in the paper we have written what kind of information
      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...

    Ofir Arkin [ofirsys-security.com]
    The Sys-Security Group
    PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA