LWN: Comments on "First Release of LibreSSL Portable Available"

First Release of LibreSSL Portable Available

rillian — Fri, 18 Jul 2014 22:19:07 +0000

Published signature also passes for

4d16b6852cbd895ed55737819d2c042b37371f1d80fcba4fb24239eba2a5d72b libressl-2.0.2.tar.gz

Voodoo coding

cladisch — Thu, 17 Jul 2014 12:23:07 +0000

And it's being added: [PATCH, RFC] random: introduce getrandom(2) system call:

The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD.
The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely.
The other feature provided by this new system call is the ability to request randomness from the /dev/urandom entropy pool, but to block until at least 128 bits of entropy has been accumulated in the /dev/urandom entropy pool.

First Release of LibreSSL Portable Available

roblucid — Wed, 16 Jul 2014 09:55:45 +0000

And changing the API so things are no-ops, looks like a recipe for unfortunate consequences eg) rand_poll() returning 1.

There's a balance to be struck, I agree with what you are saying here and don't expect a bug for bug binary compatibility, but am sceptical about the useful results and effects of the approach taken by this fork.

Fork detection

wahern — Wed, 16 Jul 2014 00:35:06 +0000

One solution is using pthread_atfork, and instead of resetting the state in the child, reset the state in the parent. Which to me seems like a better idea than getpid() because you can't always trust the child to do the right thing after returning from fork. Maybe it was compromised, and now it's leaking your entire PRNG state.

OpenBSD just added a new flag to mmap which requests the kernel to zero mapped pages in the child process after a fork. This solves all the issues. The PRNG state is gone in the child and the child will know to reseed.

Voodoo coding

dlang — Tue, 15 Jul 2014 23:39:33 +0000

well, you would get out of root as quickly as you can after establishing the chroot, and if you properly minimize the things accessible inside the chroot you make it harder to find a local exploit to get back to root.

Voodoo coding

wahern — Tue, 15 Jul 2014 20:34:50 +0000

If you setgid and setuid to a non-privileged user and don't have any open directory descriptors, how easy is it to get out?

There are issues with signal and ptrace, but those are easily fixed by using a specialized UID and GID per service.

Arguing that root can break out of a chroot jail is a strawman. Nobody runs as root inside a chroot jail.

And if you're really paranoid, neither LXC nor even full-blown virtualization is sufficient, because the Linux kernel (like all software) is riddled with bugs, and last time I checked sophisticated hackers didn't find themselves defeated by the presence of VMWare or KVM.

Voodoo coding

drag — Tue, 15 Jul 2014 18:28:39 +0000

root in chroot still has root privileges. Unless you are extremely careful breaking out of a chroot 'jail' is _VERY_ easy.

If chroot made sense from a security perspective we wouldn't have any need for things like 'LXC containers'.

Voodoo coding

busterb — Tue, 15 Jul 2014 16:55:51 +0000

Huh, ran the same test as above for Solaris on OS X 10.9.4, it would appear to have the same issue at first glance:

test: main: issetugid: 1
test: parent: issetugid: 1
test: parent: uid: 1000
test: parent: euid: 0
test: child: issetugid: 0
test: child: uid: 1000
test: child: euid: 0

Voodoo coding

busterb — Tue, 15 Jul 2014 16:41:53 +0000

Hmm, that is interesting, I'll check it out.

Solaris 10 and 11.0 also apparently have issues with issetugid, though it kind-of works (they apparently didn't patch it for 10 because not enough software used it yet?)

http://mcarpenter.org/blog/2013/01/15/solaris-issetugid(2)-bug

Though there are more issues building on Solaris 10 so far, so we haven't crossed that bridge yet.

First Release of LibreSSL Portable Available

moltonel — Tue, 15 Jul 2014 16:41:27 +0000

> My impression is, developers under-estimate usefullness of binary compatability to clued up sys admins.

My impression is, you overestimate the feasability of fixing OpenSSL without breaking binary compatibility :p You can only do so much while keeping compatibility. Some bugs are exposed in the API itself; fixing them requires changing the API and breaking compatibility. Not fixing something because it'd break compatibility is a recipe for the next blockbuster security flaw.

As annoying as it is for sysadmins and downstream projects, they won't get better security without some porting efforts.

First Release of LibreSSL Portable Available

roblucid — Tue, 15 Jul 2014 15:36:13 +0000

BoringSSL is the fork, which kept version number and sets another symbol to indicate to application it's not OpenSSL, mentioned earlier in thread.

We'll just see if there's technical/personal disagreements and long term split like Emacs, or whether a consensus can be reached. My impression is, developers under-estimate usefullness of binary compatability to clued up sys admins.

First Release of LibreSSL Portable Available

zenaan — Tue, 15 Jul 2014 10:17:22 +0000

>Each doing what suits them, with no big picture and lots of downstream excuses to shrug shoulders and do nothing which risks a costly ongoing support commitment.

Come on - patience! This is not slashdot, this is lwn.net, and at least a cursory wikipedia check ought be done before fishing for "better support" with "negativity"/ projection of assumptions etc. Not cool. Not intelligent.

From the wikipedia page for BoringSSL, checked just now:
"In June 2014, Google announced its own fork of OpenSSL dubbed BoringSSL. Google plans to co-operate with OpenSSL and LibreSSL developers.[29]"

Fork detection

cesarb — Tue, 15 Jul 2014 01:46:27 +0000

I just saw a discussion at https://news.ycombinator.com/item?id=8033779 about a potential problem with clone(): if a program forks twice (with the original process exiting before the second fork), it can end up with the same PID, breaking the "fork detection" of the PRNG (which tries to detect forks by seeing if the PID has changed).

I thought of a way around that problem, with the kernel's help: a per-process generation counter. Make it large enough (like 64 bits) and increment it with each fork. If the generation counter has changed, it's a fork even if the PID ended up the same.

The discussion on the original post has a simpler (though less reliable) workaround: comparing the process creation time.

(Perhaps the audit subsystem has some non-wrapping id which could be useful here?)

First Release of LibreSSL Portable Available

rillian — Mon, 14 Jul 2014 22:55:42 +0000

9596f6cb3e8bafe35d749dfbdb6c984f1bbd86233598eb5fdb4abf854a5792ba libressl-2.0.1.tar.gz

There's now a SHA256.sig which confirms this and the previous checksums. I verified the EC 25519 signature against the published key in the same directory with this port of OpenBSD's package signing tool.

untrusted comment: LibreSSL Portable public key RWQg/nutTVqCUVUw8OhyHt9n51IC8mdQRd1b93dOyVrwtIXmMI+dtGFe

Continuing the record here until we get a better trust path established.

Voodoo coding

wahern — Mon, 14 Jul 2014 21:20:51 +0000

Caveat emptor: On OS X issetugid is another broken stub (like pselect) which doesn't actually implement the correct behavior, but apparently thrown in so software can compile while remaining silently, delightfully bug ridden. Although at least the pselect man page documents the broken behavior.

The BSDs and Solaris implement the correct behavior, as does Linux's new getauxval(AT_SECURE). That is, the status is inherited across fork but not exec.

Voodoo coding

wahern — Mon, 14 Jul 2014 20:42:45 +0000

Nice. I was unaware of that interface, although it doesn't help with forking, etc.

But it looks like Linux finally supports a fork-safe issetugid implementation. Linux was one of the last systems which didn't provide issetugid or a similar interface for detecting whether the current process or (crucially) an ancestor was setuid or setgid. glibc had a hack in its loader for supporting secure_getenv and similar behavior, but it wasn't guaranteed to work in children because it depended on the real and effective IDs being different, which wouldn't be the case if you effectively dropped privileges.

First Release of LibreSSL Portable Available

richmoore — Mon, 14 Jul 2014 20:42:28 +0000

Indeed, Qt builds fine with 2.0.1 though I've not yet tested if it actually works.

Voodoo coding

wahern — Mon, 14 Jul 2014 20:23:48 +0000

For the record (lest somebody try to use me as a strawman), all my code always checked the return value of sysctl and fell back on /dev/urandom. If that failed my apps then went through the typical horrible hacks of manually collecting entropy, although I realize now that was a poor engineering decision--obscuring the Red Hat kernel changes for far too long--and am changing all such code to bail by default.

Voodoo coding

PaXTeam — Mon, 14 Jul 2014 20:21:00 +0000

PaX itself doesn't have the hardened chroot feature, grsecurity does.

Voodoo coding

wahern — Mon, 14 Jul 2014 20:12:38 +0000

I never said it was impossible. I said it wasn't a sane interface.

And I stand by that claim. Why make something which could fail when you don't have to and it's trivial not to?

I always try to write my server programs in a manner which can handle request failures without interrupting service to existing connections. There are various patterns to make this more convenient and less error prone, but one of the most effective is RAII (although I don't use C++), where you acquire all the necessary resources as early as possible, channeling your failure paths into as few areas as possible. I also use specialized list, tree, and hash routines which I can guarantee will allow me to complete a long set of changes to complex data structures free of OOM concerns. One must rigorously minimize the areas that could encounter failure conditions so as to ensure as few bugs as possible in the few areas that are contingent on success or failure or logical operations.

But how many applications do you know of which bother trying to ensure entropy is available in the very beginning of process startup or request servicing? How do would you even do this in a generic fashion? Is it really sane to open a descriptor for every request, or to cache a separate descriptor inside every component or library that might need randomness? If you seed another generator, how do you handle forking? getpid? pthread_atfork? There's a reason most PRNGs (CSPRNGs included) support automatic seeding; not just for convenience, but for sane behavior in the common case.

Hacks and tweaks to the kernel implementation of /dev/urandom to ensure entropy is ready as soon as possible is a perennial bicker-fest, and yet those can't compare to the contortions applications would need to go through just to maintain a descriptor. And they'd all be doing it differently! That's not a recipe for a secure application ecosystem. And getting people to use third-party libraries (like Nick Matthewson's excellent libottery) would be like herding cats and adds an unnecessary dependency. It harks back to the bad old days of EGD, before even /dev/urandom was available.

Of course it's possible. Lots of things are possible, but not all things are practical given limited human and machine resources, and even less unequivocally contribute to a safer software ecosystem free of hidden traps.

When I talk about CSPRNGs being deeply embedded within other algorithms, imagine things like a random sort, or a random UUID generator. These are almost always implemented through a single routine and normally would never need to communicate a failure because _logically_ they should never fail. And yet they could fail, even with valid input, if you rely on /dev/urandom without taking other extraordinary measures completely unrelated to the core algorithm.

Computational complexity attacks, side-channel attacks, etc, have made use of CSPRNGs useful and in many cases mandatory within many different kinds of algorithms which once upon a time could never fail.

Voodoo coding

alonz — Mon, 14 Jul 2014 20:05:29 +0000

By the way—another underutilized source of entropy in Linux programs is the vector returned by getauxval(AT_RANDOM). Sure, it is intended for use by libc (e.g. to produce stack canaries), but when nothing else is available, it can be very valuable.

Voodoo coding

alonz — Mon, 14 Jul 2014 19:57:33 +0000

Just to correct one misconception—public key encryption is not the only case where randomness is mandatory. Quite a few other crypto primitives/schemes will fail subtly when used with bad randomness. A nice overview can be found here.

Deterministic public-key encryption is an active research area; for many uses (including common cases, such as key exchange) it actually is feasible.

Voodoo coding

wahern — Mon, 14 Jul 2014 19:46:54 +0000

The problem with sysctl is that RedHat has removed sysctl syscalls by default. sysctl(2) will _always_ fail on modern stock RedHat systems. It also fails on all the Gentoo systems I've tried, but I'm not sure if that's the default or a deliberate decision by our sysadmins. I only realized this recently as I use Debian and Debian-derivatives, and despite knowing about the kernel option I never fathomed that large vendors (especially ones which make claims to stable ABIs and APIs) would knowingly disable sysctl syscalls, considering all the software (like Tor) which depended on it at the time.

So sysctl({CTL_KERN, KERN_RANDOM, RANDOM_UUID}) is no longer a viable alternative. The only way to directly access kernel randomness is through an open reference to /dev/urandom or /proc/sys/kernel/random/uuid (the /proc sysctl interface).

That's the crux of the issue. If sysctl was still available then all would be well, other than some bickering over a sysctl versus a dedicated syscall interface.

In short: sysctl(2) is dead for all practical purposes on Linux. Now Linux behaves pretty much like Solaris, which never had sysctl (a later BSD extension). A lack of sysctl is one of the most annoying things about Solaris (although that's a long list).

OS X's arc4random also relies on /dev/urandom, since it copied an early FreeBSD implementation from before FreeBSD added sysctl({CTL_RAND, KERN_ARND}). And it will silently fail if /dev/urandom isn't visible when it initially seeds! And although I've long tried to support systems like OS X, Solaris, and FreeBSD<10.0 which lacked a kernel entropy syscall, I've always considered them second-class citizens in this regard, and willing to live with a disclaimer about possible issues. But now that Linux is second-class in this regard, it's a much more intolerable situation.

Voodoo coding

andresfreund — Mon, 14 Jul 2014 19:37:47 +0000

> If I have a non-blocking server and an already established socket to a browser and want to establish a secure channel with perfect forward secrecy, and I try to generate some random numbers, but the operation of simply generating a random number could fail, do you have any idea how f'ing ugly it is to insert a _timer_ and a loop trying acquire that resource?

Why do you need a timer? Why is this different than any of the other dozen or two of things you need to do to establish a encrypted connection to another host?
If error handling in any of these parts - many of which are quite likely to fail (dns, connection establishment, public/private key crypto, session key negotiation, renegotiation) - is a fundamental structural problem something went seriously wrong.

> Of course it's possible. But it's infinitely nastier than dealing with other kinds of failures, and completely unnecessary. (And compound all of this by trying to do this in a library, lest you simply argue that one should open /dev/urandom and leave it open, which is sensible but still problematic.)

You argued that it's required to this without /dev/urandom because it is *impossible* to do error handling there. Which has zap to do with being asynchronous btw.
Note that /dev/urandom - if it actually would block significantly for the amounts of data we're talking about here - would allow for *more* of an async API than a dedicated getentropy() call. The latter basically has zero chance of ever getting that. You're making arguments up.

Voodoo coding

wahern — Mon, 14 Jul 2014 19:16:14 +0000

chdir, chroot, setgid, setuid, etc.

Linux absolutely does support chroot jails. And plenty of software does this, and it's 100% portable to almost all POSIX-compliant or POSIX-aspiring systems. (Notwithstanding the fact that chroot was removed from POSIX.)

Actually, Linux supports chroot jails more than most, as PaX has patches which can prevent even root from breaking out using the normal methods, and there are patches floating around which allow you to keep descriptors to directories outside the chroot jail open by preventing use of fchdir or openat which would allow you to break out.

Voodoo coding

ledow — Mon, 14 Jul 2014 19:15:45 +0000

I'd be much more wary of a supposedly secure program not checking the return code of a function vital to its operation than an OS that deliberately and carefully returns that code in the first place.

Most programs in the world do not care about the randomness of a RNG. Only one type really does - those that handle public key encryption. If that program fails to check THE most important part of its initialisation and not at least throw out a warning string on stderr, then there's a bigger problem than how we signal that kind of error to it.

And, personally, I'd much prefer a warning of the "deprecation" kind in my logs from init if something goes wrong with that function, than any application crashing because it can't handle a particular syscall. If people are running secure systems and ignore printk messages that tell them the program used a function that it shouldn't, then they get what they deserve.

The "exceptions in C" thing is really just another dig at the language of choice in all these matters. There are plenty of ways for a C program to signal there was a problem - for instance failing any further calls until it has been properly initialised, setting a particular flag, returning a code to callers, etc. If people still AREN'T BOTHERING to check - whatever that method is - that's pretty much the death-knell to any kind of supposedly "secure" program, to my eyes.

Voodoo coding

wahern — Mon, 14 Jul 2014 19:10:05 +0000

Anyone who manages to turn an algorithm requiring O(1) space into O(N) space, especially an algorithm existing in a definite and fixed problem space that does not nor will ever benefit from any type of abstraction (in the manner of file objects), probably shouldn't be writing software, period. (Granted, we got to where we are by contingent history, so I don't blame the people who came up with /dev/urandom, only the people who defend it despite overwhelming experience and reason.)

At the end of the day it's a QoI issue.

If I have a non-blocking server and an already established socket to a browser and want to establish a secure channel with perfect forward secrecy, and I try to generate some random numbers, but the operation of simply generating a random number could fail, do you have any idea how f'ing ugly it is to insert a _timer_ and a loop trying acquire that resource? Of course it's possible. But it's infinitely nastier than dealing with other kinds of failures, and completely unnecessary. (And compound all of this by trying to do this in a library, lest you simply argue that one should open /dev/urandom and leave it open, which is sensible but still problematic.)

But thanks for the ad hominem. Even though I check every malloc call, handle multiplicative overflow when I can't prove it's safe, and try to regularly test these failure paths (which is the most difficult of all); and despite the fact that you'd probably have to stop using Apple products, Google products, and several other services and products if you wanted to avoid using my software directly or indirectly; and not withstanding the fact that my /dev/urandom wrappers have been used in all manner of software, including derivatives in some extremely popular open source software; I guess I never thought about how easy it is to overcome the design problems with /dev/urandom.

Voodoo coding

Cyberax — Mon, 14 Jul 2014 18:54:29 +0000

Linux doesn't have chroot jails.

Voodoo coding

wahern — Mon, 14 Jul 2014 18:53:16 +0000

A chroot jail implies dropping privileges. It's not much of a jail if you can walk out.

Voodoo coding

apoelstra — Mon, 14 Jul 2014 15:26:18 +0000

> If I'm not entirely mistaken, that means that any version of LibreSSL compiled on a system with getentropy() will crash on older systems that don't support it. Bit of a disincentive to implementing it.

s/dis//

As has been argued in other posts, if there is no secure source of entropy, silent failure is deadly. I can't think of a cryptographic application which needs secure entropy but is somehow able to hobble along without it — peacefully failing just provides another opportunity for a bug to translate into hard-to-detect but seriously compromised software.

Programs which crash in bad places because they assumed they had access to cryptographic tools are buggy. If they need cryptography, they should be sanity-checking their environment on startup anyway.

Voodoo coding

rsidd — Mon, 14 Jul 2014 14:18:49 +0000

The OP said "chroot jail", not "chroot" -- presumably meaning something like the FreeBSD version.

Voodoo coding

cesarb — Mon, 14 Jul 2014 11:20:47 +0000

> This is so confused. The only correct thing to do if things fail, is well, to let them fail. Return an error, there's really no shame in that. People should be prepared that things fail.

The problem here is that C does not have exceptions.

It does no good to return an error code if everyone ignores it. It's especially bad in crypto: failure to seed the RNG results in something which _looks_ like a valid key/iv/nonce, works like a valid key/iv/nonce, but completely breaks the underlying mathematical assumptions the crypto algorithms depend on, by being easily guessable and/or not unique. Two years later, someone finally notices, and the whole Internet has to generate new keys (this has happened before).

With exceptions, ignoring the error kills the program. Without exceptions, the only sane way out is to pretend it was an uncaught exception and kill the program.

@busterb, if you are reading this, I can see where mezcalero is coming from: he's a systemd developer, and it's really bad if the init process is killed (though not nearly as bad as a crypto key compromise), so init system developers tend to develop allergies to libraries which kill their own process.

How about this suggestion: only the initial seed (and the first reseed after a fork) should kill the process on a failure return from getentropy(). If it fails on other reseeds, accept the failure (generating an extra few bytes with the RNG itself and using then as the new seed) and keep going. This way, a developer using libressl would only have to force a reseed (by trying to get a random number) at the start of the program (if you can't open a fd at that point, you have bigger problems and it's best to just dump core) and after a fork, and the developer would know the library won't randomly (heh) kill the program after that point.

> And yuck. A new syscall? Of course this can fail too. For example very likely on all kernels that dont't have that yet, i.e. all of today's...

Today's kernels shouldn't fail because they have the sysctl syscall (the idea is to try first the new syscall, then fallback to /dev/urandom, then fallback to sysctl). The idea is to get the getentropy() syscall (or equivalent; I'd propose a syscall with an extra flags parameter) into the kernel before sysctl is gone for good, so there won't be kernel versions where it all fails.

----

As an aside: it probably can't be done because of API compatibility concerns, but the way I'd do it if it was possible and didn't cause any new problems would be to open the fd to /dev/urandom early _and keep it open_ (let the kernel close it on exit or exec). If reading from an open /dev/urandom fd fails, you probably have bigger problems.

First Release of LibreSSL Portable Available

moltonel — Mon, 14 Jul 2014 09:41:28 +0000

For source-based distributions like Gentoo it's a different story : it *is* the end-user's choice (ideally) to choose between one implementation and the other. Program packages depend on a virtual library package, which depends on either library package, chosen by useflag. To choose the implementation for each program, you put the useflag on its package, and either slot the virtual package or choose the implementation in the program package.

Voodoo coding

makomk — Mon, 14 Jul 2014 09:17:17 +0000

If I'm not entirely mistaken, that means that any version of LibreSSL compiled on a system with getentropy() will crash on older systems that don't support it. Bit of a disincentive to implementing it.

First Release of LibreSSL Portable Available

jengelh — Mon, 14 Jul 2014 08:56:32 +0000

OpenBSD is numbering their shared libraries, so there is some compatibility statement. Its lifetime may not appeal to you, but it is sound enough for the filesystem (and package managers like rpm) to enable multiple versions to coexist, keeping all programs runnable (in principle).

A virtual dependency for runtime in an RPM package does not buy you anything, because SONAMEs are what counts (not only to rpm, but also ld.so), and they are different even within openssl.

>Choosing at install/link time, is static, not flexible and removes choice from end-user

It was never a end-user choice anyway. The appearance of LibreSSL added another choice for developers (next to openssl, mozilla-nss), and added a hacking opportunity for distro packagers (substituting openssl by libressl by more or less patching of source codes).

First Release of LibreSSL Portable Available

tedd — Mon, 14 Jul 2014 07:52:26 +0000

Aww, and I was just going to check the Arch repository.

Voodoo coding

Cyberax — Mon, 14 Jul 2014 07:28:17 +0000

Except that chroot is NOT a way to minimize an attack surface. The docs says so. And the root user has tons of ways to escape the chroot on Linux.

sysctl(2) is a security vulnerability.

ebiederm — Mon, 14 Jul 2014 05:57:15 +0000

sysctl(2) in the kernel has not received any maintenance for years and when the bit-rot is sufficient the code will be torn out.

Seriously. No one cares. No one has ever cared. No one is going to care.

Voodoo coding

andresfreund — Mon, 14 Jul 2014 04:39:27 +0000

> CSPRNG calls are so deeply embedded within program logic that allowing the calls to fail in the normal course of execution (I.e. hitting a descriptor limit) is as sane as allowing unsigned addition to throw an error. It's simply not a sane interface. (Of course if the CSPRNG cannot be seeded it should abort the program)

What? You compare a single instruction issue with a call that does a long series of complex mathematical computations? With kernel interaction, entropy estimation, et. al.? Really?
If you write safety critical code that's written in a way that makes it impossible or infeasible to check for errors when using a CSPRNG: Please stay away from anything I will possibly use.

I don't have particularly strong feelings for/against getentropy() but this argument isn't doing it any favors.

> Also, chroot jails _should_ be within volumes mounted nodev. Nor should /proc be visible. The point of a chroot jail is to minimize kernel attack surface.

There's some value in that argument, but I think in reality the likelihood of opening new holes in software because /dev/null, /dev/urandom, /proc/self et al. aren't available is much higher than the security benefit.

Voodoo coding

wahern — Mon, 14 Jul 2014 03:42:34 +0000

CSPRNG calls are so deeply embedded within program logic that allowing the calls to fail in the normal course of execution (I.e. hitting a descriptor limit) is as sane as allowing unsigned addition to throw an error. It's simply not a sane interface. (Of course if the CSPRNG cannot be seeded it should abort the program)

Also, chroot jails _should_ be within volumes mounted nodev. Nor should /proc be visible. The point of a chroot jail is to minimize kernel attack surface.

This is probably why OpenBSD just added a getentropy syscall to replace their sysctl interface; to allow simple, wholesale disabling of the sysctl interface entirely using systrace.

Researchers have settled on the sane behavior of a CSPRNG syscall: block until initial seeding, then never block again. And DJB has argued that once seeded the kernel CSPRNG should never be seeded again, as it would be superfluous and might provide more opportunity for malicious hardware to exfiltrate bits undetectably.

The issue is simply no longer debatable. The proper API is precisely something like getentropy.