Re: Concurrent access to /dev/urandom

From: Matt Mackall
Date: Sat Dec 11 2004 - 15:42:26 EST


On Sat, Dec 11, 2004 at 01:58:45PM -0600, Adam Heath wrote:
> On Sat, 11 Dec 2004, Theodore Ts'o wrote:
>
> > On Fri, Dec 10, 2004 at 06:22:37PM -0600, Adam Heath wrote:
> > >
> > > Actually, I think this is a security issue. Since any plain old program can
> > > read from /dev/urandom at any time, an attacker could attempt to read from
> > > that device at the same moment some other program is doing so, and thereby
> > > gain some knowledge as to the other program's state.
> >
> > It could be a potential exploit, but....
> >
> > (a) it only applies on SMP machines
> > (b) it's not a remote exploit; the attacker needs to have
> > the ability to run arbitrary programs on the local
> > machine
> > (c) the attacker won't get all of other programs' reads of
> > /dev/urandom, and
> > (d) the attacker would have to have a program continuously
> > reading from /dev/urandom, which would take up enough
> > CPU time that it would be rather hard to hide.
> >
> > That's not to say that we shouldn't fix it at our earliest
> > convenience, and I'd urge Andrew to push this to Linus for 2.6.10 ---
> > but I don't think we need to move heaven and earth to try to
> > accelerate the 2.6.10 release process, either.
>
> Is it a problem for other kernel versions? 2.4? Shouldn't this patch be
> pushed out separately to distributions?

It's a problem for all kernels back to 1.3.57 (when SMP was added) and
perhaps earlier for kernel-internal get_random_bytes users. Fixing
pre-2.6 means backporting the whole driver but not the changes in the
network area.

--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/