[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Having a single, good arc4random in Debian


I think it would be good for Debian to standardise on a single, good
arc4random implementation, available to any application that wants to
use it.

I'd like it to become ubiquitous, on all Debian arches (and eventually
other distributions).  We should ensure applications do find it and use
it, instead of using risky fallbacks like rand(), getpid() and time().
(Scan build logs for "checking.*arc4random" for example).

We could deprecate dozens of code copies, most of them unmaintained,
some having known security flaws that were fixed in later versions.

Looking further ahead, if we want to adopt sandboxing techniques, we
may want alternatives to /dev/urandom or sysctl.  That may be arch-
specific, so it would be great if we only had to implement it in one

The most obvious candidate to me is libbsd, which exports an arc4random
and some other useful things.  It has a permissive license, is very
small and has no external dependencies.  It would be important to make
sure its arc4random is good, but my point it that it is better to have
all eyes and effort concentrated on that one Debian package, than the
current situation.

There may be a POSIX standard agreed someday for posix_random(3) which
could be easily implemented as a wrapper around arc4random or vice-
versa.  [http://austingroupbugs.net/view.php?id=859]

More background information follows.  What do others think about going
in this direction;  the Debian Security Team in particular?  Thanks!

OpenBSD's arc4random has evolved from a bare RC4 stream cipher, to an
(safer?) revision discarding early keystream,  now to ChaCha20.  Its
reseeding methods have been updated to defend against fd exhaustion
or missing /dev/urandom, for lack of a certain sysctl on Linux, adding
fallbacks in case even that doesnt work, and to detect forking (which
has itself been reworked a couple of times after e.g. the getpid flaw
Andrew Ayer reported).

So we have embedded copies of arc4random and getentropy code throughout
the Debian archive, some better than others:

  * in OpenSSH Portable's openbsd-compat/
  * in OpenSMTPD's openbsd-compat/
  * in OpenNTPD's compat/
  * in signify-openbsd's arc4random.c
  * in LibreSSL Portable, if Debian ever has that.

I've been warned to leave those alone, since OpenBSD is responsible for
maintaining those code copies, and I expect they will do a good job of
that.  But I'm more concerned about:

  * getdns recently put copies in src/compat/
  * libevent has a copy of old arc4random.c
  * libdumbnet has it in src/rand.c
  * epic5 has it in source/compat.c
  * isakmpd has it in sysdep/common/libsysdep/arc4random.c
  * gtk-gnutella has it in src/lib/arc4random.c
  * rdate has it in src/arc4random.c
  * pure-ftpd has it in src/alt_arc4random.c
  * samhain embeds it inline in src/dnmalloc.c
  * newlib has one in winsup/cygwin/libc/arc4random.cc, likely unused
  * ntp has a copy of old arc4random in sntp/libevent/arc4random.c
    (embedded code from OpenBSD within embedded copy of libevent)
  * icedove has the same thing in
  * dnscrypt-proxy has it in src/libevent-modified/arc4random.c
  * cargo has an embedded copy of libressl sources having

And then there are situations where applications do... less desirable
things when they don't have a good arc4random available.

  * librpcsecgss has this gem in clnttcp_create()/clntudp_bufcreate(),
    I hope it's nothing too important:

#if defined (__linux__) || defined(__GLIBC__)
        call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec;
        call_msg.rm_xid = arc4random();

  * mediatomb does something similar:

  * qtwebkit-opensource-src calls currentTime()*10000 an EntropySource:

  * qtwebkit even has a comment that "ASLR currently only works on
    darwin (due to arc4random)", applies to openjfx also:

  * istgt falls back from arc4random() > srandomdev() > pid XOR time:

  * exim4 does the same thing:

  * opendnssec falls back to random():

  * ucarp too:

  * belle-sip too:

  * nsd too:

  * syrep too, "I hope this is random enough":

  * linux-ftpd too:

  * apr too:

  * isomaster too:

  * nsd too:

  * polarssl falls back to rand()!  Only for testsuite I think.

  * bind9 uses rand(), seeded by pid XOR time:

  * mediatomb too:

  * mcabber too, only seeded by time():

  * libxdmcp too:

  * wdm too:

  * cln too:

  * libice too, seems risky:

  * llvm-toolchain-3.6 has slightly better fallback for lack of

  * nmh does the same in sbr/m_rand.c

  * pgbouncer has its own embededded Keccak or ChaCha20 as fallback for
    lack of arc4random, and its own fallback for lack of getentropy:

  * vnc4 falls back to /dev/urandom but doesn't look robust in case it
    can't be opened/read:

  * php7.0 also tries the getrandom syscall proposed for POSIX:

  * libsodium too:

  * openssl uses the strong arc4random on OpenBSD, otherwise falls back
    to something that has been... problematic before in Debian.

... you get the idea.

Steven Chamberlain

Attachment: signature.asc
Description: Digital signature

Reply to: