Re: Concurrent access to /dev/urandom

From: Adam Heath (doogie_at_debian.org)
Date: 12/11/04

  • Next message: Jim Paris: "Re: PCI IRQ problems -- update" 
    Date:	Sat, 11 Dec 2004 13:58:45 -0600 (CST)
To: Theodore Ts'o <tytso@mit.edu>

    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?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jim Paris: "Re: PCI IRQ problems -- update"

    Relevant Pages

    • Re: Concurrent access to /dev/urandom
      ... I think this is a security issue. ... Since any plain old program can ... accelerate the 2.6.10 release process, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: SATA support merge in 2.4.27
      ... > A stable kernel is a kernel in which a new release does not induce 20 rejects ... > confidently upgrade to fix a security issue without worrying that everything ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Interrupt lost { .... }
      ... > CHS current addressable sectors: ... > not expired: security count ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: My thoughts on the "new development model"
      ... My concern is getting a real stable tree for various ... |>maintainers to base on, so that various patches for drivers, security ... Then convince the security people to port to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Patch 4/6 randomize the stack pointer
      ... debuggable patch series. ... I think you've been talking too much to another so called security ... where does Red Hat come in here? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)