libbsd and arc4random()

[Alejandro Colomar]

Hi Guillem!

On 1/4/23 04:14, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2022-12-30 at 13:29:23 +0100, Alejandro Colomar wrote:
>> glibc developers consider libbsd's arc4random(3) unsafe, since there are
>> situations in which it should drop the buffer but which can't be detected
>> (and libbsd's source code seems to acknowledge this).  They added
>> arc4random(3) in glibc with kernel support, which is safer to use.
> 
> Do you have references to that.

Sure.  Look here: 
<https://inbox.sourceware.org/libc-alpha/5c29df04-6283-9eee-6648-215b52cfa26b@cs.ucla.edu/T/>. 
  It's a very long thread, but worth reading entirely.

I CCd now Jason and Adhemerval, who did the implementation.  They may give more 
concrete details.

> The comment I see in the libbsd code
> (from the OpenBSD implementation, used in libressl too) mentions
> clone(3), but I only see as an obvious issue CLONE_PID which is only
> a problems for old kernels?
> 
>> Could you somehow make that libbsd only provide arc4random(3) if glibc
>> doesn't provide it?
> 
> AFAICS the glibc implementation uses blocking calls?

Yes.

As I understand it, you need to choose between "blocking and secure", and 
"non-blocking and insecure".  You can't have it "non-blocking and secure". 
Since arc4random(3) is documented as cryptographically secure, it needs to block.

> Which ISTR was an
> issue in the past (on Debian at least) on some systems that blocked
> during boot due to not enough entropy.

Yes, it was an issue.  From what I've read, there have been solutions for that, 
which involve storing entropy on a file so that there's entropy at boot time. 
However, I never did anything related to that, so I have no idea how it works 
really.  Hopefully Jason may have more details.

But as far as I could read, the opinion seemed to be: if someone has a real need 
for an insecure random number, they should not call arc4random(), and instead 
call getrandom(GRND_INSECURE).

BTW, Jason, would you mind sending a patch for the man pages to document 
GRND_INSECURE?  There's no documentation at all in the man pages about it.

> So switching the implementation
> could be problematic, and I'd rather people switch, by linking against
> the newer glibc version.

We have to choose between being problematic in the sense of:

-  messing with programs that need a non-blocking call even if it is insecure.
-  messing with programs that need secure numbers, even if it blocks.

Right now we're being problematic top the second.  I prefer being problematic to 
the first.  Anyway, that's something they'll probably realize soon, and fix it 
by calling some insecure non-blocking function, such as getrandom(GRND_INSECURE).

> 
>> You'll probably have to use aliases and linker magic,
>> to not load your function before the glibc one, I guess.  Or maybe just
>> compile it conditionally on the glibc version.
> 
> If the system libc contains an arc4random(3) implementation, then code
> linked against that, will always be preferred already:
> 
>    ,---
>    $ cat arc4.c
>    #include <stdlib.h>
>    int main() { arc4random(); return 0; }
>    $ gcc $(pkg-config --libs --cflags libbsd-overlay) arc4.c -o arc4
>    $ objdump -T arc4|grep arc4random
>    0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.36) arc4random
>    `---

Ahhh, that's nice.

> 
> Otherwise I guess I could use something similar to the MD5 wrappers,
> but that would need to be conditional on a system with a libc providing
> the functions. But then libbsd contains a couple of functions not
> found on glibc anyway so, this would probably be a mess (and it
> probably is already with a mixed glibc + libbsd linking).

However, I still fear that when glibc doesn't have arc4random(3), linking to 
libbsd might trigger insecure code, when the assumption is that arc4random(3) is 
always secure.  Which is what just happened in shadow.

> 
> Thanks,
> Guillem

Cheers,

Alex

P.S.: I also CCd Iker, since he probably is interested in this conversation, 
even if just to hear it, and Björn, since I expect his review for the shadow patch.

-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libbsd/attachments/20230104/caf09f7d/attachment.sig>