Date: Wed, 8 Jan 2003 12:50:21 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Nate Lawson <nate@root.org> Cc: security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak Message-ID: <20030108125021.A41969@unixdaemons.com> In-Reply-To: <Pine.BSF.4.21.0301071757500.15904-100000@root.org>; from nate@root.org on Tue, Jan 07, 2003 at 06:09:23PM -0800 References: <20030107190104.A40254@unixdaemons.com> <Pine.BSF.4.21.0301071757500.15904-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 07, 2003 at 06:09:23PM -0800, Nate Lawson wrote: > On Tue, 7 Jan 2003, Bosko Milekic wrote: > > On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote: > > 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. No, not really. Yes, the mbufs come from a vmmap that is reserved for mbufs and clusters but it doesn't mean that the underlying physical memory contains network data, necessarily. It is the case if you're getting an mbuf from the allocator cache, but as soon as you make that call to vm you no longer have that guarantee. > > 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. No. You are leaking contents but it is not necessarily network data. It may be more often than not, but there is no way to determine what the nature/source of the data is remotely. > > 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. OK, but not in a universal fashion. I think drivers with this problem should implement it locally. Not all drivers have the problem because not all network cards "forget" to pad the data with zeros. > -Nate -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org 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?20030108125021.A41969>