[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

On 16/07/14 03:06, Paul Tagliamonte wrote:
> I didn't see this yet in the thread, so:
> https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux

What's most interesting is that someone spent such effort to look for
this;  that there are so many eyes now on both the original OpenSSL and
the new LibreSSL code.  Both projects ought to benefit from this.

This was a real, but totally contrived issue with many preconditions:

* initial 'grandparent' process initialises LibreSSL's PRNG, then forks
* first-forked process does not use the PRNG yet, but forks again
* grandparent uses the PRNG for things and then exits, freeing up the
pid to be re-used
* second-forked 'grandchild' process might coincidentally get the same
pid as its grandparent
* grandchild uses the PRNG for things;  LibreSSL would not realise it
has forked if the pid is the same, so does not reseed - PRNG output
would be repeated from what the grandparent got before it exited -
possibly having security impact

The other major concern was about scary entropy-gathering code,
implemented in LibreSSL Portable for Linux as a last resort for when
/dev/urandom can't be read.  I agree that it's too risky, or:  too
difficult to prove safe and robust in any conceivable situation.
Debian's major OpenSSL bug was able to happen undetected for a while out
of similar circumstances.

A compile-time ifdef already allows to disable this fallback code and
raise SIGKILL instead, crashing the calling process.  As part of the
LibreSSL port to GNU/kFreeBSD and Hurd I would actually have asked that
we do this anyway in Debian, at least for those platforms.

It seems extreme, but the point is that something must be wrong on the
system if we get to the fallback code - /dev/urandom missing from a
chroot, or fd's exhausted, and the kernel not having a reliable sysctl
interface like OpenBSD's to get random bytes in the first place.

Steven Chamberlain

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: