Summary: | Apache2 apparent hang due to mod_auth_digest entropy starvation | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stefan Riemer <peng.ff> |
Component: | Current packages | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | ahessling, mmokrejs, security, snow |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 29932 | ||
Bug Blocks: |
Description
Stefan Riemer
2004-01-02 11:13:06 UTC
I saw this problem myself today. I disabled that module, but obviously this is unreasonable for people who need it. du -h /usr and your machine's disk will spin, and apache will start much quicker. This isn't a bug for us, and using /dev/urandom is insecure. you need to make more entropy for your machine. lots of other things will exhibit the same problem for lack of real random data (appearing to hang). The bug is imho that there is no way for the not so experienced user for knowing what is happen.. Look at the forum, there are many questions about this. The startup-script returns as usual with [ok], but this isn't true. There shoul'd be a check, if apache has spawned the workers. If this doesn't happened, then maybe an action like 'du -s /path/to/apache' for gathering randomness and a retry. impairing everybody to do a 'du -h /path/to/apache' is not a reasonable answer. look at alternate routes for more entropy data. possible routes include hardware RNG (see recent kernels), net-dev-randomness patches (in gentoo kernels i believe), or any other routes, look in up in the linux kernel mailing list archive. audio-entropyd is one possible route if you have an idle soundcard. I'm not sure for this, but is net-dev-randomness secure? Or at least more secure as /dev/urandom? The possible solutions are ok, but I think there should be a check in the startup script if apache comes up with the workers or is just waiting.. Is there a way for doing a check of /dev/random? Look in /proc/sys/kernel/random/ The way I see it with netdev-random, is since it uses the timing between network IRQs (not the data itself), the only way it can be seriously subverted is if an attacker has total control over your ethernet cable, in which case you have more serious problems anyway. /dev/urandom uses an SHA hash to cycle itself. I've added an interesting rng package to the tree, clrngd. see bug 26071 for the netdev-random waiting for gentoo-sources. *** Bug 37981 has been marked as a duplicate of this bug. *** note to self: mod_auth_digest needs 20 bytes of raw entropy to start. need to write some stuff for init.d that checks if enough entropy is available, and display warning otherwise. Hi, I agree something has to happen with the ebuild. I went to reinstall openssl, but that didn't help. Using strace on openssl I see it uses /dev/urandom. Why isn't egd and prngd available on gentoo. They are both used to generate said to be fairly good random data. Actually, the egd guy said that prngd is crap. That would affect openssl has to rebuilt to use the socket file. Please stick to teh default location and don't invent new place for it. I think it's /var/tmp/egd-pool or something similar. It seems the folks at Redhat faced this problem previously and have solved it by changing /dev/random to /dev/urandom: http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=103049 security: while i don't like the idea of using psuedo-random bits (/dev/urandom instead of /dev/random) for this, you're better qualified to tell me if it's safe to do this in this case. Re #5 The hardened-dev-sources support netdev-random. Our patches are broken out so any other kernel could include them rather trivially. Note: netdev-random does not work with pcmcia devices. Another kernel patch we are about to start reviewing. http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm4/broken-out/urandom-scalability-fix.patch --- Re: not secuirty@ just my own thoughts. I would not want to use the /dev/random device for apache.. random is a blocking device where urandom is not. Your free do do what you want.. But I/me would also prefer urandom over random in this case. Note: You can raise the entropy pool size by simply doing (this helps) sysctl -w kernel.random.poolsize=8192 And to see the current amount of random data. sysctl kernel.random.entropy_avail *** Bug 45527 has been marked as a duplicate of this bug. *** This should be fixed in 2.0.49-r1. Please test. I, for one, am still seeing this happen on my boxes. Is there a regression? This should be fixed, though the fix is still in ~arch and not arch. Please see bug 102587 for details of the fix and how to activate it on your system |