Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Steven Chamberlain <steven@pyro.eu.org> writes:
> 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.
Yes.
> 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
While in general I agree with you and other analysts that this bug is very
difficult to exploit, it's worth mentioning here that attacking binaries
by controlling PID numbers is a known attack with known proofs of concept.
If you have local access to the same system, you can force children to
have predictable PIDs with some degree of success by quickly forking while
doing something that delays the process whose child PID you want to
control. There has been some talk of implementing PID randomization
precisely to make this attack harder.
> 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.
It would be nice to have a reliable kernel interface for getting
randomness rather than relying on proper chroot configuration. I'm not
sure sysctl should be that mechanism, but I'm quite sympathetic to the
LibreSSL developers here. Relying on a device being present in a chroot
seems rather dubious.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: