Date: Tue, 7 Jan 2003 18:09:23 -0800 (PST) From: Nate Lawson <nate@root.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak Message-ID: <Pine.BSF.4.21.0301071757500.15904-100000@root.org> In-Reply-To: <20030107190104.A40254@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Jan 2003, Bosko Milekic wrote: > 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 > > So the "leaked > information" will be AT MOST 63 bytes, but practically somewhere > around 10 bytes and would be very occasional. It depends on what's the shortest reply you can induce from a host. Perhaps there's something shorter than icmp but if you're not on the same network, it has to be at least 20 bytes (ip hdr) so you can see the response. In that case, you're getting at most 26 bytes of data. > Not to mention that > it's totally undefined and random. Well, you have the guarantee that it's network data since the min mbuf size is 128 bytes and a packet must be less than 64 bytes to trigger this. > 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. Since the mbuf pool is statically allocated at boot, it's likely only mbuf hdrs or contents would leak this way. Still, this is data leakage even though it's a small channel. > 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. For cards that don't, it's the driver's responsibility to do this. Some do (xe) and some don't (ie). > 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. I believe this should be done for the same reason that pages allocated to the user are pre-zeroed. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0301071757500.15904-100000>