Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL's PRNG is Unsafe on Linux

agwa.name

Post reply on HN
Print view View original

101–110 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#101

Post by drdaeman »

quotemstr wrote: post #71
Buge wrote: post #35

Earlier quoted context omitted.

It mentions chroot jails in which you can't access /dev/urandom.

Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?

Why setup the device when you should be able to open it way prior to chrooting (if you don't - that's a proper time to abort() on my book) and keep the descriptor open for later use?

Re: LibreSSL's PRNG is Unsafe on Linux

#102

Post by xorcist »

quotemstr wrote: post #11

There's also pthread_atfork. Use that to reset the PRNG. It's a bad interface, but it'll work for this purpose. It bothers me when people very solemnly and seriously condemn systems for problems that are, in fact, amenable to reasonable solutions.

Why would you want to reseed the PRNG?

If the PRNG is good enough (no visible correlation in the statistics tests you can imagine thrown at it), and it's properly seeded with true randomness, then isn't everything peachy?

I am much more afraid of the seeding part of it than the actual algorithm. The algorithms are well studied by smart people, the actual implementation and seeding aren't always.

There mere fact that one could reseed the PRNG makes me nervous. That could be used in devious ways. But I am not a cryptographer, not even a mathematician, so don't take my word for it!

Am I wrong here? Why?

Re: LibreSSL's PRNG is Unsafe on Linux

#103

Post by xorcist »

quotemstr wrote: post #38
tcoppi wrote: post #36

Earlier quoted context omitted.

Linux since 3.4 has MADV_DONTDUMP [1], and there also appears to be a /proc filter file you can use to exclude general segments of memory from being dumped [2]. 1. http://man7.org/linux/man-pages/man2/madvise.2.html 2. http://man7.org/linux/man-pages/man5/core.5.html

It's hard to blacklist every piece of memory that might be sensitive. It's a much better idea, IMHO, to just put corefiles in a location accessible only to root. That's how Windows, OS X, Ubuntu, Android, and lots of other commercial systems work.

.. which you need to do anyway. The SSL library, and the program linked against it, can fail in a thousand more ways that generate them.

Re: LibreSSL's PRNG is Unsafe on Linux

#104

Post by vidarh »

quotemstr wrote: post #98
clarry wrote: post #97

Earlier quoted context omitted.

It becomes the application's problem. LibreSSL on its own can't really go out and obtain resources whenever it wants, nor can it ensure the application won't take these away. The application using LibreSSL would have to make LibreSSL do these things, at the right time and right place. You're pushing responsibility to users and applications and while at it admitting that it is impossible for a library to abstract it a…

LibreSSL can pre-allocate resources it needs in places where applications expect it to fail, then go on to use those resources in places where applications do not expect it to fail. Complaining about having to manage a file descriptor is strange, since LibreSSL already manages another resource, heap memory. Nobody expects LibreSSL to be able to do everything it promises if the system runs out of memory, so why should…

> Nobody expects LibreSSL to be able to do everything it promises if the system runs out of memory, so why should people expect LibreSSL to do everything it promises if the systems is misconfigured or out of file descriptors?

The issue is not that anyone expects it to do everything it promises if the system is misconfigured, but that if it should fail, it should take care to try to avoid failing in ways that could open massive security holes.

This is the issue here: The developers believe that as the existence of systems with unsafe core files is well established, their options are limited, as there is a risk of exposing enough state to less privileged users with a core dump to leave the system vulnerable. Someone building for a system they know has properly secured core files, can disable the homegrown entropy code, and the code will fail hard if /dev/urandom and sysctl() are both unavailable, and the problem goes away.

But what do you suggest they do for the case where they do not know whether failing will expose sensitive data? They've chosen the option they see as the lesser of two evils: Do as best they can - only as a fallback, mind you - and include a large comment documenting the issues.

If they had full freedom to design their own API this would not be an issue. They could e.g. have put in place a callback that should return entropy or fail in an application defined safe way, or many other options. But as long as part of the point is to be able to support the OpenSSL API, their hands are fairly tied.

Re: LibreSSL's PRNG is Unsafe on Linux

#105

Post by quotemstr »

vidarh wrote: post #99
quotemstr wrote: post #95

Earlier quoted context omitted.

Exactly what part of LibreSSL's API prohibits the maintenance of an internal file descriptor and early checks that this file descriptor can be filled with a handle to /dev/urandom? Resource management is not a "hoop". It is a fact of life.

Nothing. But nothing also prevents the client from intentionally or accidentally closing that file descriptor. As I've pointed out elsewhere, looping over all file descriptors and closing them on fork() is a common pattern for applications where you want to ensure you don't have resource leaks (whether for capacity or security). Which is fine if you have a safe way of returning errors in all code paths, but as the co…

> looping over all file descriptors and closing them on fork() is a common pattern for applications where you want to ensure you don't have resource leaks (whether for capacity or security).

Any application that does that is broken. Please stop trying to bring up this behavior as something a library needs to support. It isn't. If application try to close all file descriptors, then go on to do real work, plenty of things other than LibreSSL will break.

Would you go around calling munmap on random addresses and expect your application to keep working? Would you write a library that tried to guard against this behavior?

> if you have a safe way of returning errors in all code paths, but as the comments points out, they believe they don't.

That's an internal LibreSSL problem. There's nothing stopping the LibreSSL team from implementing the correct plumbing for telling callers errors about errors. AFAICT, there is no sequence of valid OpenSSL API calls such that the library needs entropy, but at no point in this sequence of calls can indicate failure.

The problems you highlight are not things libraries should try to work around. They're systemic issues. Libraries calling raise(SIGKILL) because their authors don't believe systems have sufficiently secured their core file generation is absurd and only makes the problem worse because it makes overall system operation less predictable. (Imagine a poor system administrator trying to figure out why his programs occasionally commit suicide with no log message or core file.)

These are not problems that require system-level fixes. They're problems that require changes from LibreSSL.

Re: LibreSSL's PRNG is Unsafe on Linux

#106

Post by vidarh »

quotemstr wrote: post #93
vidarh wrote: post #90

Earlier quoted context omitted.

Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. Yes, that would be stupid of the user of the library, but many security lapses happens because people makes stupid assumptions. Code to close all file descriptors on fork for example is fairly common, so you can not safely assume that the file descriptor remains valid.

> Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. You can absolutely rely on internal file descriptors not being closed. A program that closes file descriptors it does not own is as buggy as a program that calls free on regions of memory it does not own. A library cannot possibly be robust against this form of sabotage. The correct response to EBADF on a read of a…

> You can absolutely rely on internal file descriptors not being closed.

I've explained several times why you can't. The program that closes all file descriptors may be broken, but the big problem is that as long as the library has no safe way of reporting this to the caller without breaking the OpenSSL API, they are faced with either breaking a ton of applications or finding an alternative. And they've explained why this is not an alternative (in the copious comments in the soure):

> The correct response to EBADF on a read of an internal file descriptor is to call abort.

They have no control over whether or not this will result in an insecurely written core file that can leak data, and this is a common problem. If the person building the library knows that the environment it will be used in does not have that problem, it's one define to disable the homegrown entropy.

> The "close all file descriptors" operation is most common before exec.

I've seen it in plenty of code that did not go on to exec, to e.g. drop privileges for portion of the code.

Re: LibreSSL's PRNG is Unsafe on Linux

#107

Post by vidarh »

xorcist wrote: post #100
vidarh wrote: post #79

Earlier quoted context omitted.

The issue is not that they believe /dev/urandom to be bad, but that it flat out isn't guaranteed to be available: If you're chroot'ed, chances are you won't have read access (or see) /dev/urandom. Furthermore, if you've run out of file handles (maybe intentionally - because someone figures they can try to DOS you to attack the PRNG), it is not a given you'll be able to open it even if it's visible. LibreSSL tries /de…

Then abort if it's not available? A lot of software (most?) doesn't work with an empty /dev. At least null is othen required, so why not throw urandom in there as well?

The source explains why the developers does not see aborting as acceptable: It opens a huge security hole on systems where core files are insufficiently secured. On systems that are properly secured, it's a single define to cause it to fail hard when it can't use either /dev/urandom or sysctl().

Re: LibreSSL's PRNG is Unsafe on Linux

#108

Post by vidarh »

pbhjpbhj wrote: post #45
ryan-c wrote: post #22

Earlier quoted context omitted.

Assume a fairly busy system * Original process with PID 17519 * PID 17519 forks producing a new process with PID 26606 * PID 17519 produces some "random" bytes then exits * PID 26606 forks producing a new process with the now unused PID 17519 * New PID 17519 produces some "random" bytes, which will be the same as the "random" bytes produced by original PID 17519, causing a raptor to attack the user.

So, PID is used as part of the CSPRNG? If I get a block from /dev/urandom, then another one at some later time, what are the chances it's identical? Isn't that what you're saying here (or was the whole post intended to be comical and not just the last line). [If only it had been raining it would have taken days longer for the raptor to attack, or something /random]

Note that the article calls out two entirely separate issues:

1) The PRNG wrapper apparently depends on the pid to "detect" if there's been a fork, and so the PRNG seed will remain the same in grandparent and grandchild if you double-fork and manage to get the same pid. This may or may not be a problem - whether or not you can induce enough forks to manage to get the right pid will depend on application. This is not dependent on

2) If both /dev/urandom and sysctl() is unavailable, it falls back on generating its own entropy using a convoluted loop and lots of sources. There's all kinds of ways that can be nasty, but that relies on enough factors that just getting the same pid would be insufficient in and of itself (but it may very well reduce the entropy).

Re: LibreSSL's PRNG is Unsafe on Linux

#109

Post by quotemstr »

vidarh wrote: post #106
quotemstr wrote: post #93

Earlier quoted context omitted.

> Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. You can absolutely rely on internal file descriptors not being closed. A program that closes file descriptors it does not own is as buggy as a program that calls free on regions of memory it does not own. A library cannot possibly be robust against this form of sabotage. The correct response to EBADF on a read of a…

> You can absolutely rely on internal file descriptors not being closed. I've explained several times why you can't. The program that closes all file descriptors may be broken, but the big problem is that as long as the library has no safe way of reporting this to the caller without breaking the OpenSSL API, they are faced with either breaking a ton of applications or finding an alternative. And they've explained why…

> I've explained several times why you can't

OpenSSL is crufty in part because it's full of workarounds for ancient, crufty code. LibreSSL shouldn't repeat that mistake. LibreSSL does have ways to report allocation failure errors to callers. It shouldn't even try to work around problems arising from applications corrupting the state of components that happen to share the same process. That task is hopeless and leads to code paths that are very difficult to analyze and test. You're more likely to create an exploitable bug by trying to cope with corruption than actually solve a problem --- and closing file descriptors other components own is definitely a form of corruption.

> [LibreSSL has] no control over whether or not [abort] will result in an insecurely written core file

The security of core files simply isn't LibreSSL's business. The mere presence of LibreSSL in a process does not indicate that a process contains sensitive information. LibreSSL has no right to replace system logic for abort diagnostics. If the developers believe that abort() shouldn't write core files for all programs or some programs or some programs in certain states, they should implement that behavior on their own systems. They shouldn't try to make that decision for other systems. LibreSSL's behavior here is not only harmful, but insufficient, as the library can't do anything about other calls to abort, or actual crashes, in the same process.

> I've seen it in plenty of code that did not go on to exec, to e.g. drop privileges for portion of the code.

Please name a program that acts this way.

Re: LibreSSL's PRNG is Unsafe on Linux

#110

Post by clarry »

drdaeman wrote: post #101
quotemstr wrote: post #71

Earlier quoted context omitted.

Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?

Why setup the device when you should be able to open it way prior to chrooting (if you don't - that's a proper time to abort() on my book) and keep the descriptor open for later use?

What if the random numbers are needed not by the daemon that chroots itself, but by a separate program that gets exec()'d within the chroot?
Post reply on HN