From: smenard at nbnet.nb.ca (Stephen Menard)
Subject: leaky ethernet routers

> 
> 
> We urge people to read the paper before they cry wolf...
> 
> 
The world is falling in.....nifty-neato 
READ the PDF ping your test net...do some net traffic,,... ping again
yep simple, but timming is important to see the traffic you want

why does my.... [nasty hole nasty hole]
<fill in the blank>  database fill field ERROR

... D-Link 604 DSL router...
tell me stuff in padding? Orif explains ALL too well

Is that why i see  --^-^--  ICMP pings  ;-) on the wire; 
or are them early DARPA network guys -brighter- than we thought?

no exploit needed  :-)    Thanks BUGTRAQ ... for removing them

ping -s 1 vic.t.im.ip    #is too simple why does it work
:-{p

----- Original Message ----- 

From: "Ofir Arkin" <ofir@...-security.com>
To: <bugtraq@...urityfocus.com>
Sent: Friday, January 10, 2003 1:02 PM
Subject: More information regarding Etherleak


> 
> 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@...-security.com]
> Founder
> The Sys-Security Group
> http://www.sys-security.com
> PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
> 
> 
> 
>

Powered by blists - more mailing lists