On Thu, 9 Jan 2003, Jonathan Stone wrote:
> In message <H8GMHy.BnE@tac.nyc.ny.us>Christos Zoulas writes
> > In article  <Pine.NEB.4.44.0301091019210.4462-100000@haiku.jarai.net>,
> > Brian Chase <vaxzilla@jarai.org> wrote:

> > >  http://www.kb.cert.org/vuls/id/412115

> > 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).

Well, according to an article in eWeek, and the paper they reference
by @Stake, they're claiming (possibly incorrectly) that NetBSD suffers
from the problem:

<http://www.eweek.com/article2/0,3959,809353,00.asp?kc=EWTH102099TX1K0100487>
<http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf>

The CERT page just states that NetBSD's status is "unknown" wrt to the
vulnerability.  It might be wise for someone from core to provide some
feedback, or at least to investigate, the stated claims.

It seems like a fairly minor vulnerability, but it'd be nice to clear
the good name of NetBSD.

-brian.