5 ms·

Why must it have its own PRNG? Is there a problem asking the kernel (via /dev/urandom) for all required entropy, at the time it is needed? Or would this cause a

by rlpb 12y ago

Why must it have its own PRNG? Is there a problem asking the kernel (via /dev/urandom) for all required entropy, at the time it is needed? Or would this cause a real-world performance problem? Surely this is an obvious first question that all commentators are stepping over?

orik 12y ago
It isn't about performance, but instead /dev/urandom is believed to be a poor source of entropy by the OpenBSD developers. I believe the heart of the issue it that /dev/urandom will give you a string even if it has very low entropy at the time. You can find all sorts of articles for and against /dev/urandom and I don't really know enough to comment on it's security, but I trust the that the team working on this fork more than I trust the OpenSSL foundation.
- elithrar 12y ago
  > I believe the heart of the issue it that /dev/urandom will give you a string even if it has very low entropy at the time. On OpenBSD, /dev/urandom does the right thing, unlike Linux. As per http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ - > FreeBSD does the right thing: they don't have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.
- vidarh 12y ago
  The issue is not that they believe /dev/urandom to be bad, but that it flat out isn't guaranteed to be available: If you're chroot'ed, chances are you won't have read access (or see) /dev/urandom. Furthermore, if you've run out of file handles (maybe intentionally - because someone figures they can try to DOS you to attack the PRNG), it is not a given you'll be able to open it even if it's visible. LibreSSL tries /dev/urandom first, then falls back on a deprecated sysctl() interface, then tries it's own "last resort fallback".
  - xorcist 12y ago
    Then abort if it's not available? A lot of software (most?) doesn't work with an empty /dev. At least null is othen required, so why not throw urandom in there as well?
    - vidarh 12y ago
      The source explains why the developers does not see aborting as acceptable: It opens a huge security hole on systems where core files are insufficiently secured. On systems that are properly secured, it's a single define to cause it to fail hard when it can't use either /dev/urandom or sysctl().
      - xorcist 12y ago
        I see, but I am not convinced. I think the argument still stands. There are always other ways to crash.
- gpvos 12y ago
  You're completely wrong. According to the OpenBSD devs, on modern BSDs and Linux, /dev/urandom is as good a source of entropy as anything. It's commonly implemented by a good cryptographically secure pseudo-random generator. This code only gets called in cases where /dev/urandom is not available (for example in a chroot jail or when the file descriptor limit is reached).
  - DCKing 12y ago
    That was not his point. /dev/urandom on Linux does return low entropy strings when it simply doesn't have any at boot time. /dev/(u)random on BSD actually blocks until it has collected enough entropy to get going, and doesn't block thereafter. So BSD /dev/urandom is more secure in that it never gives bad random numbers for some baseline badness. He was not factually wrong about that, although he is wrong in stating that that was the reason the OpenBSD developers are dismissing it.
    - maxlybbert 12y ago
      You are correct about BSD /dev/urandom vs Linux /dev/urandom. But since LibreSSL isn't likely to be used at boot time, it doesn't try to work around that issue. Instead, the concern is "what should we do if we can't open /dev/urandom?" For what it's worth, the "exploit" requires (1) the user deny access to both /dev/urandom and the sysctl interface, (2) multiple levels of forks (a child never has the same PID as its parent, but a grandchild can have the same PID as its grandparent, and (3) the grandparent must exit before the grandchild (PIDs uniquely identify all running processes). It's not something that will happen by accident, even to incredibly careless programmers. But I do agree with the BSD guys that Linux should have another way to get entropy in this case (note that they have a similar file for OS X for similar reasons). And I hope it's not named CryptGenRandomBytes().
      - DCKing 12y ago
        The "unlikely"s and "by accident"s in your comment are correct if and only if you assume too much about the scenario in which LibreSSL is to be deployed. It goes far beyond web servers, you know. For example, what of routers that have no means of entropy input but interrupt timing? What of Android libraries that just use libcrypto? These systems are usually free to exploit by determined attackers! LibreSSL/OpenSSL doesn't think "unlikely" and tries to cover as much as possible. The TLS library needs to work as good as possible regardless of the context.
Buge 12y ago
It mentions chroot jails in which you can't access /dev/urandom.
- quotemstr 12y ago
  Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?
  - buster 12y ago
    How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device nodes?
    - quotemstr 12y ago
      You have to be root (well, have CAP_SYS_CHROOT) to call chroot in the first place. If you're root, you can call mknod to create your device nodes.
      - vidarh 12y ago
        It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.
        deleted 12y ago
        [deleted]
        vidarh 12y ago
        I agree, partly. The problem is that LibreSSL needs to decide what to do. The comments in the file outline why they believe they have few options: They are concerned about aborting, because of potentially unsafe core files (consider if someone lets you execute a suid process in a chroot that has access to read SSL keys you should not have access to, and you can cause it to dump a core file that you can read simply by DOS'ing access to /dev/urandom), and lack of other safe ways of reporting failure. Couple that with the fact that whether or not the /dev/ is set up correctly is a distraction: You have no guarantee that you will be able to open and read any file, as they can not guarantee that there's nothing available on the server that can't easily be used to hit file descriptor limits for a suitable process or open file limits for the entire system. So this problem is there regardless of whether or not you're willing to demand a correctly configured /dev.

by rlpb 12y ago

orik 12y ago

It isn't about performance, but instead /dev/urandom is believed to be a poor source of entropy by the OpenBSD developers. I believe the heart of the issue it that /dev/urandom will give you a string even if it has very low entropy at the time. You can find all sorts of articles for and against /dev/urandom and I don't really know enough to comment on it's security, but I trust the that the team working on this fork more than I trust the OpenSSL foundation.

elithrar 12y ago
> I believe the heart of the issue it that /dev/urandom will give you a string even if it has very low entropy at the time. On OpenBSD, /dev/urandom does the right thing, unlike Linux. As per http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ - > FreeBSD does the right thing: they don't have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.
vidarh 12y ago
The issue is not that they believe /dev/urandom to be bad, but that it flat out isn't guaranteed to be available: If you're chroot'ed, chances are you won't have read access (or see) /dev/urandom. Furthermore, if you've run out of file handles (maybe intentionally - because someone figures they can try to DOS you to attack the PRNG), it is not a given you'll be able to open it even if it's visible. LibreSSL tries /dev/urandom first, then falls back on a deprecated sysctl() interface, then tries it's own "last resort fallback".
- xorcist 12y ago
  Then abort if it's not available? A lot of software (most?) doesn't work with an empty /dev. At least null is othen required, so why not throw urandom in there as well?
  - vidarh 12y ago
    The source explains why the developers does not see aborting as acceptable: It opens a huge security hole on systems where core files are insufficiently secured. On systems that are properly secured, it's a single define to cause it to fail hard when it can't use either /dev/urandom or sysctl().
    - xorcist 12y ago
      I see, but I am not convinced. I think the argument still stands. There are always other ways to crash.
gpvos 12y ago
You're completely wrong. According to the OpenBSD devs, on modern BSDs and Linux, /dev/urandom is as good a source of entropy as anything. It's commonly implemented by a good cryptographically secure pseudo-random generator. This code only gets called in cases where /dev/urandom is not available (for example in a chroot jail or when the file descriptor limit is reached).
- DCKing 12y ago
  That was not his point. /dev/urandom on Linux does return low entropy strings when it simply doesn't have any at boot time. /dev/(u)random on BSD actually blocks until it has collected enough entropy to get going, and doesn't block thereafter. So BSD /dev/urandom is more secure in that it never gives bad random numbers for some baseline badness. He was not factually wrong about that, although he is wrong in stating that that was the reason the OpenBSD developers are dismissing it.
  - maxlybbert 12y ago
    You are correct about BSD /dev/urandom vs Linux /dev/urandom. But since LibreSSL isn't likely to be used at boot time, it doesn't try to work around that issue. Instead, the concern is "what should we do if we can't open /dev/urandom?" For what it's worth, the "exploit" requires (1) the user deny access to both /dev/urandom and the sysctl interface, (2) multiple levels of forks (a child never has the same PID as its parent, but a grandchild can have the same PID as its grandparent, and (3) the grandparent must exit before the grandchild (PIDs uniquely identify all running processes). It's not something that will happen by accident, even to incredibly careless programmers. But I do agree with the BSD guys that Linux should have another way to get entropy in this case (note that they have a similar file for OS X for similar reasons). And I hope it's not named CryptGenRandomBytes().
    - DCKing 12y ago
      The "unlikely"s and "by accident"s in your comment are correct if and only if you assume too much about the scenario in which LibreSSL is to be deployed. It goes far beyond web servers, you know. For example, what of routers that have no means of entropy input but interrupt timing? What of Android libraries that just use libcrypto? These systems are usually free to exploit by determined attackers! LibreSSL/OpenSSL doesn't think "unlikely" and tries to cover as much as possible. The TLS library needs to work as good as possible regardless of the context.

Buge 12y ago

It mentions chroot jails in which you can't access /dev/urandom.

quotemstr 12y ago
Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?
- buster 12y ago
  How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device nodes?
  - quotemstr 12y ago
    You have to be root (well, have CAP_SYS_CHROOT) to call chroot in the first place. If you're root, you can call mknod to create your device nodes.
    - vidarh 12y ago
      It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.
      - deleted 12y ago
        [deleted]
        vidarh 12y ago
        I agree, partly. The problem is that LibreSSL needs to decide what to do. The comments in the file outline why they believe they have few options: They are concerned about aborting, because of potentially unsafe core files (consider if someone lets you execute a suid process in a chroot that has access to read SSL keys you should not have access to, and you can cause it to dump a core file that you can read simply by DOS'ing access to /dev/urandom), and lack of other safe ways of reporting failure. Couple that with the fact that whether or not the /dev/ is set up correctly is a distraction: You have no guarantee that you will be able to open and read any file, as they can not guarantee that there's nothing available on the server that can't easily be used to hit file descriptor limits for a suitable process or open file limits for the entire system. So this problem is there regardless of whether or not you're willing to demand a correctly configured /dev.