The OpenBSD project late last night rushed out a patch for a vulnerability in the LibreSSL pseudo random number generator (PRNG).
The flaw was disclosed two days ago by the founder of secure backup company Opsmate, Andrew Ayer, who said the vulnerability was a “catastrophic failure of the PRNG.”
OpenBSD founder Theo de Raadt and developer Bob Beck, however, countered saying that the issue is “overblown” because Ayer’s test program is unrealistic. Ayer’s test program, when linked to LibreSSL and made two different calls to the PRNG, returned the exact same data both times.
“It is actually only a problem with the author’s contrived test program,” Beck said. “While it’s a real issue, it’s actually a fairly minor one, because real applications don’t work the way the author describes, both because the PID (process identification number) issue would be very difficult to have become a real issue in real software, and nobody writes real software with OpenSSL the way the author has set this test up in the article.”
Ayer’s contention is that the PRNG in LibreSSL, which is a fork of OpenSSL, is unsafe to use after a fork; forking, he said, creates a clone of the parent process and as a result, the PRNG will generate identical output in the parent and child processes unless the PRNG is reseeded, Ayer said.
“LibreSSL attempts to detect when a fork occurs by checking the PID,” Ayer said. “If it differs from the last PID seen by the PRNG, it knows that a fork has occurred and automatically reseeds. This works most of the time. Unfortunately, PIDs are typically only 16 bits long and thus wrap around fairly often. And while a process can never have the same PID as its parent, a process can have the same PID as its grandparent. So a program that forks from a fork risks generating the same random data as the grandparent process. This is what happens in the fork_rand program, which repeatedly forks from a fork until it gets the same PID as the grandparent.”
This scenario, De Raadt said, is unrealistic.
“The way it is forking is just not what any program using libssl/libcrypto does. The ‘danger’ only exists in that specific choice of operations, yet no piece of software does that,” de Raadt said. “This test program has been specifically constructed to exercise this completely synthetic test. The author’s test program is holding all the pid’s captive so that this situation happens. It is simply unrealistic.
“The OpenSSL random number generator has a number of far worse practices in it, which we have decided to not bring to light further; our decision was to remove it and replace it, and we will do better,” de Raadt said.
Ayer conceded in an email to Threatpost last night that the test case depends on an unusual program structure and the “normally unlikely” scenario of the grandchild process getting the same PID as its grandparent.
“However, there are a lot of programs that use OpenSSL and it’s impossible to say for sure that none of them have this structure. It’s also imprudent to say that an attacker won’t find a way to manufacture the duplicate PID scenario in a real system. Time and time again, potential security vulnerabilities are dismissed as being impractical, only for clever attackers to find a way to exploit them in practice a few years later,” Ayer said. “Also, since LibreSSL is billed as a drop-in replacement for OpenSSL, I think it’s a bug if you can demonstrate a program that performs safely under OpenSSL’s guarantees but not when used with LibreSSL. You can’t anticipate all the unusual ways a library might be used, and in a
security-sensitive library the consequences of breaking guarantees can be severe.”
LibreSSL 2.0.0 and 2.0.1 were released over the weekend and support a number of platforms beyond OpenBSD, including several Linux flavors, as well as Mac OS X and Solaris.
The OpenBSD Foundation announced its intention to fork OpenSSL in April and spent considerable time before then and since cleaning up volumes of code that bloated OpenSSL. LibreSSL surfaced after the disclosure of the Heartbleed OpenSSL vulnerability.
The release of these early versions of LibreSSL was meant to generate the kind of feedback Ayer delivered, de Raadt and Beck said.
“This is exactly what I was aiming for with my blog post,” Ayer said. “In general, I really like the work the LibreSSL devs are doing. I think it’s in the true open source spirit that we’re having this discussion, and it should ultimately lead to better security for all.”
