Date: Mon, 27 Nov 2017 20:51:36 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: AES_CTR_DRBG / random numbers * Darcy Parker <darcyparker@...il.com> [2017-11-27 11:39:00 -0500]: > I learned about it from > https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/. > My understanding of it is limited, but enough to be concerned about claimed > risk of how fork() may copy memory used by an initialized random number leaks across fork were discussed in 2014 (when libressl was developed) it's unreasonable to expect a security boundary between parent and forked child without leaks into the child. use exec in the child to get better isolation or avoid sensitive state in the parent. (i think this should be the goal) it's unreasonable to expect library authors to fix up their code using non-standard apis to correctly mark all sensitive state. (i think this should not be the goal) i don't think it's the job of a tls library to make library use across fork safe, it cannot do that since the boundary that needs protection can be huge and a library has no business interfering with application level concerns (maybe the fork semantics was used on purpose). otoh there is a real practical security issue here and the implemented madvise flag is a solution for it (but i think it aims for the wrong goal and thus not a good long term solution for the ecosystem). > generator. It looks like s2n and linux have or will adopt AES_CTR_DRBG. > My concern is other software that may depend on libc's rand() rather than > implement their own secure pseudo random number generator. > > I appreciate musl for its reputation of correctness and performance. And > although I saw glibc is moving to it, a quick set of searches with Google > didn't uncover discussion about AES_CTR_DRBG being implemented in musl. > > Is musl's pseudo random number generator methods vulnerable in the same way > glibc is? My hope is that it is not vulnerable, but if it is, I'd like to > know musl developers are already on top of this. libc prng is another discussion: rand() has well defined semantics that openbsd currently observably breaks in the name of security. i don't think this is good behaviour: it breaks existing software and changes user expectations in unrealistic ways. libc has several prng apis, none of them are particularly well designed, and certainly not for cryptographic use, if really that's what users want then the standard should at least allow that (currently it does not). musl currently provides as good prng as possible given the constraints of the apis. what musl does not provide is a cprng, adding arc4random (non-standard but existing practice) or waiting for the api proposed for posix were discussed earlier as well as adding getrandom syscall wrapper, maybe these can be considered again..
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ