Subject: Ethernet frame padding bug - CERT VU #412115 (xs4)
To: NetBSD tech-security list <tech-security@netbsd.org>
From: Rogier Krieger <rogier@virgiel.nl>
List: tech-security
Date: 01/13/2003 16:17:44
Hi everyone,

earlier today, I received a warning on a bug in NIC drivers that
could exist on many platforms. A company named @stake discussed a
possible leakage of information in padded ethernet frames. In the
padding, other recent traffic passing through the machine was
included. CERT labeled this vulnerability VU#412115.

Here's a part of the overview in the @stake advisory that was
released, describing the issue [1]:

"Multiple platform ethernet Network Interface Card (NIC) device
drivers incorrectly handle frame padding, allowing an attacker to
view slices of previously transmitted packets or portions of kernel
memory. This vulnerability is the result of incorrect implementations
of RFC requirements and poor programming practices, the combination
of which results in several variations of this information leakage
vulnerability."

Since I couldn't find a NetBSD statement on this vulnerability so
far, I was curious and decided to test for myself.

Testing on my local NetBSD/i386 (v1.6, up to date as of SA2002-29), I
seem to get rather safe results. All endings of the packages seem to
contain the same data so far as padding is concerned. Below is a
tcpdump for several ping packets to and from the machine named
'karres'. To me it seems padding is handled just fine.

15:55:30.887090 valhalla.iverdahl > karres.iverdahl: icmp: echo request
(ttl 32, id 24388, len 60)
0x0000   4500 003c 5f44 0000 2001 f212 c0a8 6418        E..<_D........d.
0x0010   c0a8 6401 0800 3e5c 0200 0d00 6162 6364        ..d...>\....abcd
0x0020   6566 6768 696a 6b6c 6d6e 6f70 7172 7374        efghijklmnopqrst
0x0030   7576 7761 6263 6465 6667 6869                  uvwabcdefghi
15:55:30.887214 karres.iverdahl > valhalla.iverdahl: icmp: echo reply (ttl
255, id 42963, len 60)
0x0000   4500 003c a7d3 0000 ff01 ca82 c0a8 6401        E..<..........d.
0x0010   c0a8 6418 0000 465c 0200 0d00 6162 6364        ..d...F\....abcd
0x0020   6566 6768 696a 6b6c 6d6e 6f70 7172 7374        efghijklmnopqrst
0x0030   7576 7761 6263 6465 6667 6869                  uvwabcdefghi

Can anyone confirm NetBSD is not vulnerable? The @stake report seems
to test only up to 0x0020, but linux already includes HTTP-snippets
before that point. To quote from the @stake report [2], linux may do:

14:51:11.315842 192.168.222.11 > 192.168.222.25: icmp: echo reply (DF) (ttl
128, id 895, len 28)
0x0000   4500 001c 037f 4000 8001 b9eb c0a8 de0b        E.....@.........
0x0010   c0a8 de19 0000 cef8 b406 7d00 743a 204d        ..........}.t:.M
0x0020   6f7a 696c 6c61 2f35 2e30 2028 5769                  ozilla/5.0.(Wi
14:51:50.318904 192.168.222.11 > 192.168.222.25: icmp: echo reply (DF) (ttl
128, id 1435, len 28)
0x0000   4500 001c 059b 4000 8001 b7cf c0a8 de0b        E.....@.........
0x0010   c0a8 de19 0000 a7f8 b406 a400 6b65 6570        ............keep
0x0020   2d61 6c69 7665 0d0a 436f 6f6b 6965                  -alive..Cookie

It seems like a false alarm for NetBSD. It just can't hurt to check
up on it - I may have missed something, although a packet of 60 bytes
long should be enough testing material.

Greets,

Rogier Krieger


[1] The @stake advisory
[ http://www.@stake.com/research/advisories/2003/a010603-1.txt ]

[2] Full @stake report
[
http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf ]

[3] CERT VU#412115 - Network device drivers reuse old frame buffer
data to pad packets
[ http://www.kb.cert.org/vuls/id/412115 ]