Bugzilla Bug 46038

By default, when using non-clear authentication (cram-md5, digest-md5, etc),
sasl accesses /dev/random for random data to using in building hashes and keys.
Unfortunately, because A) /dev/random blocks when the kernel has not gathered
enough entropy, B) the kernel gathers entropy largely from keypresses and other
random user-driven events, and C) many (most?) servers have no user at the
console, we end up with a situation where /dev/random is constantly starved for
entropy. This make almost every non-clear authentication block, sometimes for
many minutes, before the user can continue, which is horrible. The delay is
often long enough to time out the client connection and kill the connection
attempt entirely which is horrible^2. Even worse, this wastes the  precious
entropy that had already been gathered for that attempt, further exacerbating
the problem, which is horrible^3. The final result is that secure
authentication is unusable.

Fortunately, the solution is simple. Direct sasl to use /dev/urandom instead of
/dev/random. The cyrus-sasl devs discuss this problem in reference to APOP
(because for APOP it blocks even clear authentication because a hash is
generated for the headerline of ALL POP connections) at
http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Cyrus/POP3DevRandomIssue.
However, the problem actually extends far beyond APOP, affecting all non-clear
authentication. They do specifically say that sasl does not have a need for
high-quality randomness as /dev/random provides, and suggest the use of
/dev/urandom to solve this problem.

To address this and similar issues, I propose that a new global USE flag,
"urandom", be added which causes any application build that supports it to use
/dev/urandom instead of /dev/random.

Changes for the cyrus-sasl ebuild in particular are trivial:
Add "urandom" to IUSE and this line to src_compile:

    use urandom && myconf="${myconf} --with-devrandom=/dev/urandom"

Thanks much.

Note: I'm sorry if I made a bad call by marking this as MAJOR, but the major
feature of SASL is secure authentication, and in my opinion, this major feature
is currently BROKEN.

Reproducible: Always
Steps to Reproduce:
1. emerge cyrus-sasl
2. Do any significant amount of non-clear sasl authentication.
Actual Results:  
Almost all non-clear authentications block after AUTH, often for many minutes, 
often timing out the connection.

Expected Results:  
All authentications should respond instantaneously, and not block.

I notice new (still masked) ebuilds are using use_with. To match that, I
changed my ebuild so urandom is added to IUSE and this is added to src_compile:

  myconf="${myconf} `use_with urandom devrandom /dev/urandom`"

Still works fine for me.

I'd like to confirm that the patch works as advertise. :)

this is what I've gathered:

# grep '\(\/dev\/random\|\/dev\/urandom\)' /usr/portage/* -R | grep ebuild
dev-java/xerces/xerces-2.6.2.ebuild:    addpredict /dev/random
dev-java/xerces/xerces-2.6.1.ebuild:    addpredict /dev/random
dev-java/xerces/xerces-2.6.2-r1.ebuild: addpredict /dev/random
dev-java/xerces/xerces-2.6.0.ebuild:    addpredict /dev/random
media-sound/audio-entropyd/audio-entropyd-0.0.6.ebuild:DESCRIPTION="Audio-entropyd generates entropy-data for the /dev/random device."
net-dns/bind/bind-9.2.3.ebuild:         mknod ${CHROOT}/dev/random c 1 8
net-dns/bind/bind-9.2.2-r3.ebuild:              mknod ${CHROOT}/dev/random c 1 8
net-dns/bind/bind-9.2.2.ebuild:         mknod ${CHROOT}/dev/random c 1 8
net-dns/bind/bind-9.2.2-r2.ebuild:              mknod ${CHROOT}/dev/random c 1 8
net-dns/bind/bind-9.2.2_rc1-r2.ebuild:          mknod ${CHROOT}/dev/random c 1 8
net-dns/bind/bind-9.2.2-r1.ebuild:              mknod ${CHROOT}/dev/random c 1 8
net-dns/pdnsd/pdnsd-1.1.11.ebuild:      [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom"
net-dns/pdnsd/pdnsd-1.1.9.ebuild:       [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom"
net-dns/pdnsd/pdnsd-1.1.10.ebuild:      [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom"
net-www/apache/apache-2.0.49-r1.ebuild:         --with-devrandom=/dev/urandom \
net-www/apache/apache-2.0.49-r3.ebuild:         --with-devrandom=/dev/urandom \
sys-libs/nss-mysql/nss-mysql-0.43-r1.ebuild:    cmd="${ROOT}/bin/dd if=/dev/random bs=32k count=1 2>/dev/null | md5sum | awk '{print \$1}'"

It looks like only net-dns/pdnsd and net-www/apache are configured with "devrandom" and they both configured to use /dev/urandom. As the reporter stated /dev/random is almost not usable, so I think we could just configure cyrus-sasl to use /dev/urandom without the need of USE flag.

diff snipset:

                --with-dbpath=/etc/sasl2/sasldb2 \
+               --with-devrandom=/dev/urandom \
                ${myconf} || die "econf failed"

That would certainly be fine with *me*. I was just concerned that a) it might
turn off the paranoids :D and b) it might go against the Gentoo philosophy of
choice. I suppose if other packages are doing it, though...  ;)

I disagree with some of the arguments here, however, I do realize there is a
need for more flexibility with cyrus-sasl.

First of all, if a server does not have enough entropy, that is the
administrator's problem. The Gentoo hardened team has provided a number of ways
to gather entropy in a server environment: netdev-random kernel patches
(network devices can contribute to entropy), audio-entropyd (gather entropy
from sound card mic input), and hardware random device turned on by default in
the kernel config. Hardened has even addressed SSP entropy-draining issues by
making an "erandom" USE flag for glibc. It's an administrator's job to make
sure a server has enough entropy. Using the /dev/urandom device only hides the
problem.

I think that if Gentoo makes decisions based on a USE variable as to which
random device to use, this will raise many security concerns. Switching between
blocking and non-blocking devices can be problematic. It's not just an issue of
strength of encryption. The decision to use a particular random device should
be code-dependent (an upstream decision), and in many cases different code in
the same package may make use of different devices.

If cyrus-sasl says that /dev/random is not necessary, why do they still default
to using it? It seems to me that the cyrus-sasl developers should resolve this
issue.

My first instinct is that the devs really should make this a runtime option.
Unfortunately, they have not done so, and I've seen no indication that they
intend to (they feel it's too easily addressed at compile time, and I see their
point). Gentoo, on the other hand, is supposed to be all about choice. A USE
flag would address the problem without impacting the security of those not
using it. Many other packages do similar things (see the USE flags
"artswrappersuid" and even netcat's "GAPING_SECURITY_HOLE"). A great many
packages go so far as to have full-blown source patches applied based on USE
flags, certainly far more impacting than simply changing a random-device.

You say that it's an admin's responsibility to make sure his/her server has
entropy. I disagree: I believe it's every admin's responsibility and right to
*decide* how much entropy his/her server needs.

The possibility of exotic kernels and kernel patches was also discussed. It is
unfair to suggest that such kernels are the only way to run an application as
UNexotic as "mail server." It's even less reasonable once you consider that you
want me to go to the trouble of running that kernel, deal with the resulting
incompatibilities, install a sound card that a mail server doesn't need, and
have my kernel constantly poll these entropy sources (of questionable quality
in the case of the network interface), which all increases the load on my
server, all for the purpose of gathering entropy *I don't need*.

---OR---

Make a two-line change to the ebuild.

It hurts noone, helps many, and gives us choices.

Ok, I still hold the same optinion here, so I'll just address your comments,
Mike.

The issue with the cyrus-sasl maintainers is simple. Does it matter if pulling
from a random device blocks? If it doesn't, use /dev/random. If it does, use
/dev/urandom. It sounds like they probably have done this, and are refusing to
change the behavior for the same reason I am!

/dev/random is constantly replenishing. If you do not have enough entropy to
return random data at a paricular time, the worst that could happen is that an
application has a slight delay until there is enough data.

If there is so much activity on a server that the entropy available stays at 0,
then the administrator has failed. There are dozens of secure applications that
absolutely require entropy-chcked random data. cyrus-sasl is just one of many.
Are you going to ask us to modify every single app so that it uses
/dev/urandom?  Yhis isn't really just about one package.

An administrator certainly has the right to simply "give up" and decide that
they cannot address the entropy problem. If that is the case, using
/dev/urandom is not even the right answer! /dev/urandom still depletes system
entropy. The correct solution is to use a psuedo-random device such as
/dev/erandom. This may seem new and ridiculous, but I believe that is because
of the great deal of misunderstanding surrounding random devices. It is only
now, unfortunately, being addressed, and hopefully the frandom/erandom patch
will be added to the default kernel tree sooner rather than later. All someone
has to do is read
/usr/src/linux/drivers/char/random.c to understand this issue, but no one ever
does.

Choosing a kernel is your choice. Gentoo makes it very easy.

Show me proof of concept code that you can influence kernel random data from an
external network interface with the netdev-random patch. Netdev-random has been
available for abour 3 years now.

If you are concerned about entropy and true security on your server, then your
server probably needs a sound card. It sounds ridiculous, but it's true. Either
that or make sure the motherboard has a hardware random device.

Polling the devices mentioned for data to contribute to entropy barely touches
your server load. Have you tried it? I run these things on a dozen servers and
have no load problems.

Adding a local use flag may seem like a simple thing, but from a larger
perspective, it's too easy to use this type of solution as a band-aid rather
than addressing the real issue.

I would be willing to make a local use flag, called "BADIDEA" or something
remeniscent of the netcat ebuild. I would much rather support the "erandom" use
flag and have cyrus-sasl use /dev/erandom, which is the correct solution for
admins that do not care about encryption security.

What does everyone else think?

Actually, /dev/erandom would be a wonderful solution. If that will make it into
the main sources soon, I'd be all for that.

To answer your question, no, I'm not for adding a urandom option to all
packages that use entropy (you've convinced me that a global use flag is,
indeed, a bad idea). Only ones for which the quality of that entropy is not
important, (such as this one, as stated by upstream). If cyrus-sasl is the only
such case, then so be it.

Please keep in mind that /dev/urandom is not /dev/zero. :D It still provides
decent-quality entropy, it just may be of *lower* quality than /dev/random is
guaranteed to be.

Mike, for now please take a look at rng-tools.

# emerge -s rng-tools
Searching...
[ Results for search key : rng-tools ]
[ Applications found : 1 ]

*  sys-apps/rng-tools
      Latest version available: 1.1
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 78 kB
      Homepage:    http://gkernel.sourceforge.net/
      Description: Daemon to use hardware random number generators.
      License:     GPL-2

I did consider rng-tools, but unfortunately, my mobo has no hardware RNG. :(

I have cyrus-imap running on a server hosted under user mode linux, and it is
perpetually short on entropy in /dev/random.  When I used the default
cyrus-sasl saslauthd for authentication, it took about 60 seconds for me to see
my mail.  I edited my cyrus-sasl-2.1.19-r1.ebuild and added a urandom flag,
restarted my services, and now it takes about one second.  I need a urandom USE
flag for cyrus-sasl.

Created an attachment (id=41390) [details]
Patch to cyrus-sasl-2.1.19-r1.ebuild adding urandom USE flag

This patch adds urandom support for cyrus-sasl.

Ken,
Please read comment #7.

I'd like to point out that the documentation referenced by Cory
(/usr/src/linux/drivers/char/random.c), actually states that /dev/urandom is
cryptographically strong, while the author of frandom/erandom
(http://frandom.sourceforge.net/) specifically recommends against using
frandom/erandom for cryptographic purposes (though he also says there doesn't
seem to be a hard reason it shouldn't be ok - go figure).

For me, without or with the patch here under, cyrus-sasls-2.19-r1 fails with
this access violation summary : 

open_wr:   /dev/random
open_wr:   /dev/random
open_wr:   /dev/random


This is the command :

[ebuild  N    ] dev-libs/cyrus-sasl-2.1.19-r1  -authdaemond -berkdb -debug
+gdbm +java -kerberos +ldap +mysql +pam -postgres +ssl -static +urandom  0 kB


I've even tried to change the access right of /dev/random, but same result.

mindtech@, your problem have nothing to do with this bug, see bug #57693 if it
solve your problem.

@ comment #10
If your system doesn't have hardware RNG, rng will fall back to /dev/urandom

# /etc/init.d/rngd start
 * Starting hardware RNG daemon ...
 * No hardware RNG found, using /dev/urandom as feedback input            [ ok ]

closing as WONTFIX.

Well, at least that makes the ebuild work. I certainly don't consider it ideal,
since this means compromising the randomness of all applications using
/dev/random, including those that, unlike cyrus-sasl, *do* need good randomness
(like persistent key pair creation, for example).

But, if you refuse, you refuse. What more can I do? Se la' vie. I'll continue
to put in the one-line fix recommended by upstream myself when new versions
come out, ad infinitum.

*sigh*

On second thought, one more try at pointing you guys at what upstream says. I just noticed that they now state it even more clearly than before, at http://asg.web.cmu.edu/cyrus/download/sasl/sysadmin.html :

"The included mechanisms, besides OTP and SRP, use random numbers only to generate nonces, so using /dev/urandom is safe if you aren't using OTP or SRP."

To answer Cory's conjecture that they don't change to /dev/urandom because they tested it and it didn't work: the above states flat-out that your assumption is incorrect. The only reason /dev/random is the default is that there are SOME configurations (namely, those using OTP and/or SRP) for which it *is* crucial. At present, these are not commonly used (yet, anyway), so /dev/urandom is perfectly fine. USE flags are for being able to set compile options in the most appropriate way for the user's environment, and this is a perfect example of something that varies by environment. I don't understand why you refuse to use the "USE" functionality for exactly the purpose for which it was designed. Furthermore, given your own arguments that high-quality randomness is so important for some applications (and it is), I'm simply aghast that your proposed solution is to use rngd on hardware without an RNG to subvert /dev/random's entropy entirely.

I'm reopening the bug just to make sure someone looks at this again since I've provided a new citation where upstream makes it clear. Continue being wrong and WONTFIX it again if you must.

I think we should add a USE flag to use /dev/urandom instead a /dev/random. I
think so because:

1) Is gentoo philosophy
2) Doesn't do any harm to those people using /dev/random
3) It's also upstream's opinion

I can take care of it if no one oposses.

Cheers,
Ferdy

Added urandom useflag in cyrus-2.1.20-r2.

Cheers,
Ferdy

FWIW, I've been using /dev/random in the same way the bug reporter describes
for > 1 year now and I've never seen the problem discussed by the bug reporter.
 Nice to have the option of /dev/urandom I guess, but I just never had the need
for it.

As I said, it only tends to affect servers with significant numbers of
connections using encrypted SASL authentication, thereby significantly draining
entropy (note that this leaves out most users, who use default mail client
settings and such that use insecure connections - my server, for example,
*only* allows encrypted IMAP authentication, as well as encrypted
authentication for SMTP relaying). Further, it is more pronounced on headless
systems where there is zero user interaction at the console (like mine) which
is the usual source of entropy.

In any case, whether you've seen it or not is irrelevant. It's a known fact. I
don't imagine you'd expect Gentoo to remove all USE flags that you yourself
don't happen to use, correct?

*** Bug 110119 has been marked as a duplicate of this bug. ***