PDA

Bekijk Volledige Versie : More information regarding Etherleak



Ofir Arkin
10/01/03, 19:45
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

Peter Turczak
17/01/03, 06:15
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 10 January 2003 18:02, Ofir Arkin wrote:
> 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
>
I audited our system running under various operating systems.
The following OS do _not_ pad the packets with zero but something else, i=
f=20
anybody is interested in the dumps of the frames produced while testing, =
feel=20
free to contact me.

Machine=09=09OS=09=09Version

IBM iSeries=09OS/400=09
IBM RS/6000=09AIX =09=094.3
Sun E450=09=09Solaris=098
HP Printers=09=09JetDirect=09Various

Identification of the vunerability was done by "ping -s1 <host>" and anal=
ysing=20
the resulting answers using ethereal, looking if the ethernet trailer was=
=20
different from all zero.


Greetings=20

Peter Turczak

- --

WIWA Gmbh&Co KG
Networking Dept.
Gewerbestr. 1-3
D-35633 Lahnau
GERMANY

Voice: ++49-6441-609-12
FAX: ++49-6441-609-50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+H1ZDEOIt4Nhv5cwRAuU8AJ0a0BpdY2rq90RKk0nlx5 KiNPZrqQCaAmPY
G7CtTaw8qKWLvLvRTlOM+28=3D
=3Dr8NM
-----END PGP SIGNATURE-----

Manuel Bouyer
21/01/03, 08:32
On Sat, Jan 11, 2003 at 12:24:49AM +0100, Peter Turczak wrote:
> I audited our system running under various operating systems.
> The following OS do _not_ pad the packets with zero but something else, if
> anybody is interested in the dumps of the frames produced while testing, feel
> free to contact me.
>
> Machine OS Version
>
> IBM iSeries OS/400
> IBM RS/6000 AIX 4.3
> Sun E450 Solaris 8
> HP Printers JetDirect Various

In the case of the E450, the hardware does the ethernet padding. It does
with values different from 0 (0x55 in the 2 machines I tested, E420 and Ultra5),
but it doesn't come from host memory.

--
Manuel Bouyer <bouyer@antioche.eu.org>
{Net,Free}BSD: 22 ans d'experience feront toujours la difference
--

Basil Hussain
21/01/03, 09:49
Hi,

> I audited our system running under various operating systems.
> The following OS do _not_ pad the packets with zero but something
> else,

> HP Printers JetDirect Various

I have just tested a HP JetDirect J6035A by pinging with the 1-byte method
from a Windows 2000 workstation. Whilst pinging, I continually refreshed the
web admin interface of the JetDirect to generate some HTTP traffic. I
captured the following ICMP Echo Reply packet clearly showing part of an
HTTP request/response.

00 B0 D0 EE | 8A BE 00 01 | E6 45 3C 65 | 08 00 45 00 [.........E<e..E.]
00 1D 21 38 | 00 00 40 01 | 82 E0 C0 A8 | 2A D2 C0 A8 [..!8..@.....*...]
2A A5 00 00 | 42 FF 02 00 | 5A 00 61 18 | 0D E4 50 10 [*...B...Z.a...P.]
16 D0 E4 86 | 00 00 48 54 | 54 50 2F 31 | [......HTTP/1]

So, it would appear that this particular model of HP JetDirect is
vulnerable, and doesn't pad with random data. It may be advisable to more
closely investigate HP JetDirect devices.

On another note, in CERT's information, they include a statement from Cisco
stating that "all of the latest shipping versions of Cisco IOS releases in
the 12.1 and 12.2 trains are not vulnerable". They do not mention other
Cisco operating systems.

I tested a Cisco PIX 515 firewall appliance running PIX O/S version 6.0(1)
and found that it wasn't vulnerable. A packet typical of those I have logged
shows all null bytes for the padding:

00 B0 D0 EE | 8A BE 00 03 | 6B F6 6C 35 | 08 00 45 00 [........k.l5..E.]
00 1D E5 D8 | 00 00 FF 01 | FF 47 C0 A8 | 2A C9 C0 A8 [.........G..*...]
2A A5 00 00 | 93 FF 02 00 | 09 00 61 00 | 00 00 00 00 [*.........a.....]
00 00 00 00 | 00 00 00 00 | 00 00 00 00 | [............]

Regards,
Basil Hussain

Manuel Bouyer
22/01/03, 17:31
On Fri, Jan 17, 2003 at 06:25:52PM +0100, Peter Turczak wrote:
> Well this correct as long as you don't use the Sun fcal and gbit card. This

Strange, all gbic atapters I know do automatic padding

> one does again not pad with a constant value, so i guess it is vunerable.
>
> 0000 00 0a 27 7d d2 c6 08 00 20 fc e9 ca 08 00 45 00 ..'}.... .....E.
> 0010 00 1d af d7 40 00 ff 01 45 c8 c0 a8 02 28 c0 a8 ....@...E....(..
> 0020 02 c7 00 00 8c a9 73 4c 00 0a 00 00 00 00 00 00 ......sL........
> 0030 00 00 00 00 00 00 00 00 00 00 00 00 31 48 fe 98 ............1H..
> Interesting is that most bytes of the pad are zero, but the last four are not,
> this is correct for all packets i got out of our Sun.

Ha, how long is your packet ? 60 or 64 byte ?
If it's 64 then the 4 last bytes are the ethernet CRC. I also made this
mistake when testing some drivers, until I noticed the len was not what I
expected it to be :)
As you seem to have captured a multiple of 16 bytes, I suspest it's 64...

--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 23 ans d'experience feront toujours la difference
--