* Re: AES_CTR_DRBG / random numbers
2017-11-27 16:39 AES_CTR_DRBG / random numbers Darcy Parker
@ 2017-11-27 17:13 ` Markus Wichmann
2017-11-27 17:25 ` Darcy Parker
2017-11-27 19:51 ` Szabolcs Nagy
2017-11-27 23:34 ` Rich Felker
2 siblings, 1 reply; 6+ messages in thread
From: Markus Wichmann @ 2017-11-27 17:13 UTC (permalink / raw)
To: musl
On Mon, Nov 27, 2017 at 11:39:00AM -0500, Darcy Parker wrote:
> Hi,
>
> Have musl developers considered AES_CTR_DRBG like glibc project has?
>
> 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
> 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.
>
That's retarded!
Sorry, I should contain my vitriol. The fact that rand() is insufficient
for cryptohraphic applications should be well known to any programmer
attempting to write such a thing. As is the fact that fork() copies your
address space (or at least that's the observable effect).
It might, of course, be less well known to the programmers actually
putting an SSL library into their forking server, but in that case the
documentation is insufficient. It would probably be better to not fork,
but spawn a thread instead. That way, PRNG state would be shared with
the parent and all siblings, meaning that no two threads would generate
the same sequence of random numbers.
> 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.
>
It is, and it could not work any other way. The state of all PRNGs is
copied upon fork(). The only way to get around this is to reseed the
PRNGs in either process after forking. (Or, alternatively, exec()ing in
either process will also wipe the PRNG state).
A process that needs secure random numbers will have to read from
/dev/urandom anyway.
> Thanks
> Darcy
Ciao,
Markus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AES_CTR_DRBG / random numbers
2017-11-27 17:13 ` Markus Wichmann
@ 2017-11-27 17:25 ` Darcy Parker
2017-11-27 17:44 ` Markus Wichmann
0 siblings, 1 reply; 6+ messages in thread
From: Darcy Parker @ 2017-11-27 17:25 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
Thanks - that's what I wanted to hear.
Sorry for the retarded question... I wrote this as a user and not a
developer who knows about these things. When I read in the article that
glibc was changing their PRNG, it raised alarms of what else (other than
SSL) could be vulnerable. I accept that if a developer didn't know it is a
documentation problem. Maybe its not as big a deal for libc
implementations as it sounded in that article.
On Mon, Nov 27, 2017 at 12:13 PM, Markus Wichmann <nullplan@gmx.net> wrote:
> On Mon, Nov 27, 2017 at 11:39:00AM -0500, Darcy Parker wrote:
> > Hi,
> >
> > Have musl developers considered AES_CTR_DRBG like glibc project has?
> >
> > 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
> > 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.
> >
>
> That's retarded!
>
> Sorry, I should contain my vitriol. The fact that rand() is insufficient
> for cryptohraphic applications should be well known to any programmer
> attempting to write such a thing. As is the fact that fork() copies your
> address space (or at least that's the observable effect).
>
> It might, of course, be less well known to the programmers actually
> putting an SSL library into their forking server, but in that case the
> documentation is insufficient. It would probably be better to not fork,
> but spawn a thread instead. That way, PRNG state would be shared with
> the parent and all siblings, meaning that no two threads would generate
> the same sequence of random numbers.
>
> > 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.
> >
>
> It is, and it could not work any other way. The state of all PRNGs is
> copied upon fork(). The only way to get around this is to reseed the
> PRNGs in either process after forking. (Or, alternatively, exec()ing in
> either process will also wipe the PRNG state).
>
> A process that needs secure random numbers will have to read from
> /dev/urandom anyway.
>
> > Thanks
> > Darcy
>
> Ciao,
> Markus
>
[-- Attachment #2: Type: text/html, Size: 3547 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AES_CTR_DRBG / random numbers
2017-11-27 17:25 ` Darcy Parker
@ 2017-11-27 17:44 ` Markus Wichmann
0 siblings, 0 replies; 6+ messages in thread
From: Markus Wichmann @ 2017-11-27 17:44 UTC (permalink / raw)
To: musl
On Mon, Nov 27, 2017 at 12:25:23PM -0500, Darcy Parker wrote:
> Thanks - that's what I wanted to hear.
>
It was? I mean, I flat out confirmed your security worries.
> Sorry for the retarded question... I wrote this as a user and not a
> developer who knows about these things. When I read in the article that
> glibc was changing their PRNG, it raised alarms of what else (other than
> SSL) could be vulnerable. I accept that if a developer didn't know it is a
> documentation problem. Maybe its not as big a deal for libc
> implementations as it sounded in that article.
>
Ah, alright. Sorry for the profanity, then.
BTW, the change that actually prevents the issue this article talked
about was this new madvise() flag that clears some memory in the child
process. That would reliably reset any PRNG. Why glibc are also changing
their PRNG algorithm to this AES_CTR_DRBG thingy I don't know.
Also BTW, could you please refrain from top-posting? Netiquette and
stuff (ease of reading, for the most part).
Ciao,
Markus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AES_CTR_DRBG / random numbers
2017-11-27 16:39 AES_CTR_DRBG / random numbers Darcy Parker
2017-11-27 17:13 ` Markus Wichmann
@ 2017-11-27 19:51 ` Szabolcs Nagy
2017-11-27 23:34 ` Rich Felker
2 siblings, 0 replies; 6+ messages in thread
From: Szabolcs Nagy @ 2017-11-27 19:51 UTC (permalink / raw)
To: musl
* Darcy Parker <darcyparker@gmail.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..
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AES_CTR_DRBG / random numbers
2017-11-27 16:39 AES_CTR_DRBG / random numbers Darcy Parker
2017-11-27 17:13 ` Markus Wichmann
2017-11-27 19:51 ` Szabolcs Nagy
@ 2017-11-27 23:34 ` Rich Felker
2 siblings, 0 replies; 6+ messages in thread
From: Rich Felker @ 2017-11-27 23:34 UTC (permalink / raw)
To: musl
On Mon, Nov 27, 2017 at 11:39:00AM -0500, Darcy Parker wrote:
> Hi,
>
> Have musl developers considered AES_CTR_DRBG like glibc project has?
>
> 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
> 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.
rand() is fundamentally not usable for cryptographic purposes or
anything where even moderately high-quality pseudorandom sequences are
needed, since it is fundamentally only capable of producing 2^32
possible sequences (one for each seed). There are not any
cryptographic random number APIs in musl, but the proposed
posix_random and/or arc4random are under consideration. If one is
chosen, a secure backend algorithm will of course be used. Most of the
hype about this topic is a matter of choosing fast ones while
minimizing the security tradeoffs; otherwise unless you intentionally
choose some backdoored rube-goldberg-esque one, there's not a lot to
worry about.
The fork() topic is also over-hyped. Switching to a new security
context after fork() without exec*() is fundamentally a security bug;
it leaks all sorts of potentially-sensitive information beyond just
csPRNG state. Modern design is to exec after forking (or preferably,
use posix_spawn instead of fork+exec to avoid this issue, get much
better performance, and be compatible with targets without fork).
Ensuring that the fork child gets a new csPRNG sequence distinct from
the parent's is just a one-line change to the fork function; it does
not need the fancy kernel help (madvise stuff). This also serves to
reduce the likelihood that child will get access to sensitive state.
But ensuring that no state that could be used to partly or fully
recover the csPRNG state leaks to the child is essentially impossible
without assistance at all stages of the toolchain and runtime.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread