On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote: > The short of it is that if a tx packet is < 64 bytes (min ethernet frame > len), data can be leaked if the driver transmits 64 bytes. It seems our > use of mbufs would prevent leakage but I haven't examined any drivers to > verify this. > > http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf > > -Nate
Heh! This seems like a pretty long paper for what it's worth. I can see how we could have the same "problem" but keep in mind the scope of the issue (the paper blows it out of proportion, I think, for someone who may not necessarily understand the issue too well): we're talking about very small packets here, under 64 bytes. So the "leaked information" will be AT MOST 63 bytes, but practically somewhere around 10 bytes and would be very occasional. Not to mention that it's totally undefined and random. An "attacker" might as well just rely on temperature to guess at how to interpret what he/she's seeing in those few bytes. The data in our case is probably DMA'd straight out of the mbuf's data region so what you'll probably find in there is just randomness from something before, not necessarily network data. Moreover, as the paper does mention, although the RFCs do appear to specify that for packets that are padded to the minimum ethernet packet size the padded bytes should be zeroed, it's pretty ambiguous as to where the zero-ing should happen. As noted, some cards will do the zeroing onboard. If you really see this as a 'security problem' then feel free to zero the padded bytes manually in the problematic drivers. Doing it universally would be too much in my opinion, especially given that some hardware takes care of it itself. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
