Date: Tue, 07 Jan 2003 19:44:52 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= <mikko@rsasecurity.com> To: Nate Lawson <nate@root.org> Cc: Bosko Milekic <bmilekic@unixdaemons.com>, security@freebsd.org, net@freebsd.org Subject: Re: @stake advisory: etherleak Message-ID: <20030107192435.B70415-100000@atlas.home> In-Reply-To: <Pine.BSF.4.21.0301071757500.15904-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Jan 2003, Nate Lawson wrote: > On Tue, 7 Jan 2003, Bosko Milekic wrote: [...] > > 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. This is definitely a security problem. It is also not new. First time I saw it was over five years ago; we could "poll" data from machines running various unix flavours. Just by pinging them we got snippets of data from inside the kernel of the target machine, including data from local connections and pipes. It was actually pretty easy to demonstrate significant leakage of recognizable information. $.02, /Mikko P.S. "rl" bzeros padding. Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security 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?20030107192435.B70415-100000>