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
This archive was generated by hypermail 2b30 : Fri Jan 10 2003 - 09:46:19 PST