From the article LibreSSL's PRNG is Unsafe on Linux.

The first version of LibreSSL portable, 2.0.0, was released a few days ago (followed soon after by 2.0.1). Despite the 2.0.x version numbers, these are only preview releases and shouldn't be used in production yet, but have been released to solicit testing and feedback. After testing and examining the codebase, my feedback is that the LibreSSL PRNG is not robust on Linux and is less safe than the OpenSSL PRNG that it replaced.

Consider a test program, fork_rand. When linked with OpenSSL, two different calls to RAND_bytes return different data, as expected:

$ cc -o fork_rand fork_rand.c -lcrypto $ ./fork_rand Grandparent (PID = 2735) random bytes = f05a5e107f5ec880adaeead26cfff164e778bab8e5a44bdf521e1445a5758595 Grandchild (PID = 2735) random bytes = 03688e9834f1c020765c8c5ed2e7a50cdd324648ca36652523d1d71ec06199de

When the same program is linked with LibreSSL, two different calls to RAND_bytes return the same data, which is a catastrophic failure of the PRNG:

$ cc -o fork_rand fork_rand.c libressl-2.0.1/crypto/.libs/libcrypto.a -lrt $ ./fork_rand Grandparent (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c Grandchild (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c


Unfortunately, when I suggested the second change on Hacker News, a LibreSSL developer replied:

The presence or need for a [RAND_poll] function should be considered a serious design flaw.

Question: Is this bug a design flaw in Linux or was this an error that the LibreSSL devs made?

  • You are asking if the free software written by the developers is an error by the developers or a design flaw by the developers? I defer to the developers and wonder about your motives. – Jeff-Inventor ChromeOS Aug 16 '14 at 10:29
  • 1
    Your question, "was it a design flaw or an error" poses a false dichotomy. A design flaw is an error, so if it was the first, then it is also the second. – atk Aug 16 '14 at 13:56
  • 1
    Design flaw in Linux VS. LibreSSL bug, it's not that hard. I didn't know there are trolls on stackexchange. – evachristine Aug 16 '14 at 14:11

Philosophical differences. LibreSSL is designed under the philosophy that an SSL library should be an SSL library, and nothing more. This means it doesn't try to implement half of libc, or provide other OS-level facilities, and it should not compensate for flaws in the OS -- the OS should be fixed instead. A pool of high-quality entropy is one of those facilities that the OS should provide.

That said, describing RAND_bytes as "unsafe" is overstating things. It's only unsafe under Linux under very limited conditions:

  1. The program uses the old-fashioned fork/exec model of threading, rather than the newer pthreads model.
  2. The program must have a structure where a grandparent process forks a parent process and exits, then the parent process forks a child process that, by chance, gets the same PID as the grandparent. This is, to put it mildly, a highly unusual program structure.
  3. The grandparent and grandchild processes both use LibreSSL's PRNG, while the process in between them does not. This is again a highly unusual program structure, as a typical program will either perform SSL operations exclusively in the grandparent (connection-handling process with a group of worker threads) or in the grandchildren (process manager with a group of connection-handling threads).
  • The level of detail you get into is quite interesting, and it'd be even better to know why those conditions specifically and not others. What does that trigger and why is this the only unsafe case? – Steve DL Aug 16 '14 at 20:46
  • 1
    1) pthreads shares memory among all threads, so there's only one random pool for RAND_bytes to draw from, where fork/exec gives each process its own memory space. 2) is the only structure that can have a PID reused by a descendant process (mostly; you can have additional fork/exec pairs between grandparent and grandchild). 3) is required for the child process to think its PID is that of the grandparent rather than that of the parent. – Mark Aug 17 '14 at 19:55

The answer is a little murky, somewhere between the two.

Linux has historically exposed the kernel's random number generator as /dev/random and /dev/urandom while BSD exposes it with the getentropy syscall. It turns out there are some advantages to the BSD approach, and because of LibreSSL pressure, Linux will be implementing a similar syscall. more info

LibreSSL primarily targets BSD, so they are favoring the syscall approach. Another principle of LibreSSL development is that they will NOT take excessive pains for portability or backward-compatibility. I presume your version of Linux does not have this syscall, and I expect that LibreSSL makes no great effort to support your version of Linux.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.