Subject: Re: Ethernet vulnerabilty [CERT vulnerability note VU#412115]
To: Christos Zoulas <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/09/2003 11:12:38
In message <H8GMHy.BnE@tac.nyc.ny.us>Christos Zoulas writes
>In article <Pine.NEB.firstname.lastname@example.org>,
>Brian Chase <email@example.com> wrote:
>>The CERT site lists the status of NetBSD's drivers with respect to this
>>vulnerablity as "unknown". Does anyone know whether our ethernet
>>drivers suffer from the the listed vulnerability?
>>The above url details the problem.
>For most modern chips this is a non-issue because they do automatic
>padding (now what they pad with, god knows; I hope it is zeros)...
>For the most popular vintage chips (eg. lance) we pad zeros manually.
>There are others that might be broken (3c501).
I suspect the real issue here is that Linux kernels, when generating
ICM errors, always returned some minimum number of bytes of original
IP data --- in some cases, more bytes than the incoming datagram which
triggered the ICMP message. The resulting datagram was larger than
ETHERMIN, in which case padding isn't the problem per se: the
prior contents of physical memory of the linux skb (quite possibly
sensitive data) ended up in the outbound ICMP message.
We don't do _that_ (or didn't, when I looked last year).
If theres concern, we could add a sysctl'able option to make
ether_output() explicitly pad runts with zeros, out to ETHERMIN.