Bug#387448: empty entropy pool leads to DOS
user [EMAIL PROTECTED] usertags #387448 close-20070831 thanks On Thu, Sep 14, 2006 at 02:57:38PM +0200, Yuri D'Elia wrote: I know this has been reported before to death [since gnutls is being used], but I will just add another twist, since I'm tired of rebuilding exim with OpenSSL manually. It looks like the workarounds that we have implemented in the mean time have improved the situation. Can you confirm this? If so, I'd like to close this bug. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On Mon, Sep 18, 2006 at 09:58:39PM +0200, Yuri D'Elia wrote: On 18 Sep 2006, at 12:53, Marc Haber wrote: I'm not native english speaker, so I did my best. Thanks. I will commit some changes to the docs, but am not going to make it sound like using the gnutls-bin/openssl based approach is mandatory. Of course, but please emphasize that it's recommended for the reasons stated (that was my intention). Is the documentation change in 4.63-4 acceptable? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On Sun, Sep 17, 2006 at 05:26:04PM +0200, Yuri D'Elia wrote: On 16 Sep 2006, at 23:48, Marc Haber wrote: Upstream quickly tagged as this as can't be done: I'd say this simply wrong. Everything can be done, provided enough time is given. Do you really think that it should be exim's job to re-implement a good part of a TLS library? Please take this up with upstream or the tech ctte. This is not what I meant. I clearly don't want to touch and library code. exim upstream has just said that it is impossible to avoid blocking from within exim as the gnutls calls themselves block. My point is that this behavior in Exim is broken, and tagging it as won'tfix is not admitting it is. Please discuss this with upstream. I'd rather invoke a key generation process in the background from the init script if dh parameters are not present. If you can you check if exim has TLS enabled, looks fine. Yes, we can check that. I have build that intelligence into the script and have also refactored the code in a way that it allows exim4_refresh_gnutls-params to be called any time. Please send a patch. Please notice that i reserve the right to change your words while applying the patch. I'm not native english speaker, so I did my best. Thanks. I will commit some changes to the docs, but am not going to make it sound like using the gnutls-bin/openssl based approach is mandatory. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On Sun, Sep 17, 2006 at 06:14:07PM +0200, Andreas Metzler wrote: Thanks, I have commited the fallback-to-openssl stuff to SVN (I have changed preferences to still prefer gnutls, though). May I ask why you hae gnutls preferred? openssl is more economically handling entropy, and if both are present, I don't think that it hurts to have the more economic tool used. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 2006-09-18 Marc Haber [EMAIL PROTECTED] wrote: [...] Thanks. I will commit some changes to the docs, but am not going to make it sound like using the gnutls-bin/openssl based approach is mandatory. I think both of us agree that generating the parameters offline is indeed superior and there no pain or effort required; the docs should reflect that imho. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 2006-09-18 Marc Haber [EMAIL PROTECTED] wrote: On Sun, Sep 17, 2006 at 06:14:07PM +0200, Andreas Metzler wrote: Thanks, I have commited the fallback-to-openssl stuff to SVN (I have changed preferences to still prefer gnutls, though). May I ask why you hae gnutls preferred? Linking against gnutls but prefering openssl just seemed strange to me. openssl is more economically handling entropy, and if both are present, I don't think that it hurts to have the more economic tool used. Fair enough. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 18 Sep 2006, at 12:53, Marc Haber wrote: I'm not native english speaker, so I did my best. Thanks. I will commit some changes to the docs, but am not going to make it sound like using the gnutls-bin/openssl based approach is mandatory. Of course, but please emphasize that it's recommended for the reasons stated (that was my intention). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 16 Sep 2006, at 23:48, Marc Haber wrote: Upstream quickly tagged as this as can't be done: I'd say this simply wrong. Everything can be done, provided enough time is given. Do you really think that it should be exim's job to re-implement a good part of a TLS library? Please take this up with upstream or the tech ctte. This is not what I meant. I clearly don't want to touch and library code. I can imagine forking a secondary process to generate the keys upon startup, a thread if GnuTLS is thread safe, or whatever. I'm perfectly fine with the cron solution. My point is that this behavior in Exim is broken, and tagging it as won'tfix is not admitting it is. I'd rather invoke a key generation process in the background from the init script if dh parameters are not present. If you can you check if exim has TLS enabled, looks fine. Please send a patch. Please notice that i reserve the right to change your words while applying the patch. I'm not native english speaker, so I did my best. Maybe the Suggest: can also be raised to a Recommend too. I think that Suggests: is appopriate, as of Policy 7.2. If you disagree, please take this to the tech ctte. Ok. If you plan to incorporate the use of openssl in cron.daily/exim4- base, change this to a gnutls-bin | openssl then. Patches attached. exim4-base.patch Description: Binary data
Bug#387448: empty entropy pool leads to DOS
On 2006-09-17 Yuri D'Elia [EMAIL PROTECTED] wrote: [...] Ok. If you plan to incorporate the use of openssl in cron.daily/exim4- base, change this to a gnutls-bin | openssl then. Patches attached. Thanks, I have commited the fallback-to-openssl stuff to SVN (I have changed preferences to still prefer gnutls, though). http://lists.alioth.debian.org/pipermail/pkg-exim4-cvs-changes/2006-September/001324.html I will let Marc look over the documentation changes. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 2006-09-14 Yuri D'Elia [EMAIL PROTECTED] wrote: Package: exim4 Version: 4.63-3 Severity: important I know this has been reported before to death [since gnutls is being used], but I will just add another twist, since I'm tired of rebuilding exim with OpenSSL manually. GnuTLS drains the entropy pool much more quickly than OpenSSL. On server systems without hardware generators, /dev/random drains very quickly, meaning that exim will often block. But exim should NOT block, or even wait, in STARTTLS. It is possible to make the system drain its entropy and then issue several connections all waiting in STARTTLS, until the maximal number of connection is reached. Combine this with the fact that it is possible to maintain the connection alive for eternity with a SO_KEEPALIVE connection, and also exim doesn't seem to terminate the process when the connection is closed in this state, and you get very easy denial of service which will refuse all further (including normal) connections. This is a bug in exim. exim should NOT block in STARTTLS. keys must be generated in background or by other means, and the unavailability of data at STARTTLS should generate and immediate temporary failure to avoid other DOS conditions. Hello, Do you have gnutls-bin installed at all? The only thing causing exim to block on STARTTLS is key and dh-param generation. Both is done offline (/etc/cron.daily/exim4-base invoking /usr/share/exim4/exim4_refresh_gnutls-params which uses certtool). Normal STARTTLS connection does not block, as it only reads from /dev/urandom. -- [EMAIL PROTECTED]:/tmp$ cat /proc/sys/kernel/random/entropy_avail ; for i in 1 2 3 4 ; do swaks -tls --silent -s localhost -q ehlo ; cat /proc/sys/kernel/random/entropy_avail ; done 3953 1 1 1 1 -- -- argenau:/tmp/GNUTLS11# strace -v -f -s 164 -eopen -p 2455 Process 2455 attached - interrupt to quit Process 12999 attached [pid 12999] open(/etc/hosts, O_RDONLY) = 3 [pid 12999] open(/etc/hosts, O_RDONLY) = 3 [pid 12999] open(/var/spool/exim4/gnutls-params, O_RDONLY|O_LARGEFILE) = 3 [pid 12999] open(/etc/exim4/exim.key, O_RDONLY) = 3 [pid 12999] open(/etc/exim4/exim.crt, O_RDONLY) = 3 [pid 12999] open(/dev/urandom, O_RDONLY) = 3 Process 12999 detached --- SIGCHLD (Child exited) @ 0 (0) --- Process 13003 attached [pid 13003] open(/etc/hosts, O_RDONLY) = 3 [pid 13003] open(/etc/hosts, O_RDONLY) = 3 [pid 13003] open(/var/spool/exim4/gnutls-params, O_RDONLY|O_LARGEFILE) = 3 [pid 13003] open(/etc/exim4/exim.key, O_RDONLY) = 3 [pid 13003] open(/etc/exim4/exim.crt, O_RDONLY) = 3 [pid 13003] open(/dev/urandom, O_RDONLY) = 3 Process 13003 detached --- SIGCHLD (Child exited) @ 0 (0) --- Process 13007 attached [pid 13007] open(/etc/hosts, O_RDONLY) = 3 [pid 13007] open(/etc/hosts, O_RDONLY) = 3 [pid 13007] open(/var/spool/exim4/gnutls-params, O_RDONLY|O_LARGEFILE) = 3 [pid 13007] open(/etc/exim4/exim.key, O_RDONLY) = 3 [pid 13007] open(/etc/exim4/exim.crt, O_RDONLY) = 3 [pid 13007] open(/dev/urandom, O_RDONLY) = 3 Process 13007 detached --- SIGCHLD (Child exited) @ 0 (0) --- Process 13011 attached [pid 13011] open(/etc/hosts, O_RDONLY) = 3 [pid 13011] open(/etc/hosts, O_RDONLY) = 3 [pid 13011] open(/var/spool/exim4/gnutls-params, O_RDONLY|O_LARGEFILE) = 3 [pid 13011] open(/etc/exim4/exim.key, O_RDONLY) = 3 [pid 13011] open(/etc/exim4/exim.crt, O_RDONLY) = 3 [pid 13011] open(/dev/urandom, O_RDONLY) = 3 Process 13011 detached --- SIGCHLD (Child exited) @ 0 (0) --- -- cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On 16 Sep 2006, at 15:39, Andreas Metzler wrote: Hello, Do you have gnutls-bin installed at all? The only thing causing exim to block on STARTTLS is key and dh-param generation. Both is done offline (/etc/cron.daily/exim4-base invoking /usr/share/exim4/exim4_refresh_gnutls-params which uses certtool). I noticed that gnutls-bin was suggested after the maintainer reply. Since I already have openssl installed, I simply ignored the suggestion. I'm happy the parameters can be generated outside of exim, as this downgrades the severity (somewhat) of the problem. Upstream quickly tagged as this as can't be done: I'd say this simply wrong. Everything can be done, provided enough time is given. Generating the keys outside of exim is one solution, and it's already implemented. If exim insists on supporting keys generation in STARTTLS, special handling MUST be implemented to avoid the DoS condition, because generating keys IS supposed to wait indefinitely. IMHO, refusing to generate the keys on-the-fly and emitting a temporary local problem until the keys are ready avoids the race without requiring heavy modifications on the exim side. The other peer can always refuse to initiate the transfer until tls is ready. Until this is fixed, exim supports flawed behavior. This is not debian related however, so I'll manage with upstream directly. About Debian. Since the race _can_ be avoided (my bad I didn't notice), I'd say that it's a priority to inform users enough. A simple Suggest isn't enough, as proven by the reports already filed. Maybe examples/exim-gencert in exim4-base should call the cron job in order to generate the keys immediately. README.Debian, instead of suggesting to check /dev/random, should inform that generation of keys in STARTTLS is subject to dossability, and thus, when setting up TLS and generating the certificates, the relative keys should be generated immediately too (this should be enough since README.Debian is referenced in main/03_exim4-config_tlsoptions), mentioning that gnutls-bin is _required_ to perform the task. Also note that openssl can be used to generate the keys (in fact, I'm using openssl now), which is a problem less. Maybe the Suggest: can also be raised to a Recommend too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
On Sat, Sep 16, 2006 at 06:09:35PM +0200, Yuri D'Elia wrote: On 16 Sep 2006, at 15:39, Andreas Metzler wrote: The only thing causing exim to block on STARTTLS is key and dh-param generation. Both is done offline (/etc/cron.daily/exim4-base invoking /usr/share/exim4/exim4_refresh_gnutls-params which uses certtool). I noticed that gnutls-bin was suggested after the maintainer reply. Since I already have openssl installed, I simply ignored the suggestion. I'm happy the parameters can be generated outside of exim, as this downgrades the severity (somewhat) of the problem. It is now more clearly documented. Upstream quickly tagged as this as can't be done: I'd say this simply wrong. Everything can be done, provided enough time is given. Do you really think that it should be exim's job to re-implement a good part of a TLS library? Please take this up with upstream or the tech ctte. About Debian. Since the race _can_ be avoided (my bad I didn't notice), I'd say that it's a priority to inform users enough. A simple Suggest isn't enough, as proven by the reports already filed. What should we do? Maybe examples/exim-gencert in exim4-base should call the cron job in order to generate the keys immediately. I'd rather invoke a key generation process in the background from the init script if dh parameters are not present. README.Debian, instead of suggesting to check /dev/random, should inform that generation of keys in STARTTLS is subject to dossability, and thus, when setting up TLS and generating the certificates, the relative keys should be generated immediately too (this should be enough since README.Debian is referenced in main/03_exim4-config_tlsoptions), mentioning that gnutls-bin is _required_ to perform the task. Please send a patch. Please notice that i reserve the right to change your words while applying the patch. Also note that openssl can be used to generate the keys (in fact, I'm using openssl now), which is a problem less. Please send a patch. Maybe the Suggest: can also be raised to a Recommend too. I think that Suggests: is appopriate, as of Policy 7.2. If you disagree, please take this to the tech ctte. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
Package: exim4 Version: 4.63-3 Severity: important I know this has been reported before to death [since gnutls is being used], but I will just add another twist, since I'm tired of rebuilding exim with OpenSSL manually. GnuTLS drains the entropy pool much more quickly than OpenSSL. On server systems without hardware generators, /dev/random drains very quickly, meaning that exim will often block. But exim should NOT block, or even wait, in STARTTLS. It is possible to make the system drain its entropy and then issue several connections all waiting in STARTTLS, until the maximal number of connection is reached. Combine this with the fact that it is possible to maintain the connection alive for eternity with a SO_KEEPALIVE connection, and also exim doesn't seem to terminate the process when the connection is closed in this state, and you get very easy denial of service which will refuse all further (including normal) connections. This is a bug in exim. exim should NOT block in STARTTLS. keys must be generated in background or by other means, and the unavailability of data at STARTTLS should generate and immediate temporary failure to avoid other DOS conditions. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9-ac11 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages exim4 depends on: ii exim4-base4.63-3 support files for all exim MTA (v4 ii exim4-daemon-light4.63-3 lightweight exim MTA (v4) daemon exim4 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
reassign #387448 exim4-daemon-light,exim4-daemon-heavy tags #387448 confirmed upstream help user [EMAIL PROTECTED] usertags #387448 gnutls forwarded #387448 http://www.exim.org/bugzilla/show_bug.cgi?id=390 thanks On Thu, Sep 14, 2006 at 02:57:38PM +0200, Yuri D'Elia wrote: I know this has been reported before to death [since gnutls is being used], but I will just add another twist, since I'm tired of rebuilding exim with OpenSSL manually. GnuTLS drains the entropy pool much more quickly than OpenSSL. On server systems without hardware generators, /dev/random drains very quickly, meaning that exim will often block. But exim should NOT block, or even wait, in STARTTLS. As far as I know, exim blocks if no dh-parameters are available. The package regenerates the dh-parameters from outside exim if the gnutls-bin package is installed. exim4-base suggests gnutls-bin for this reason. This is a bug in exim. exim should NOT block in STARTTLS. keys must be generated in background or by other means, This is already been done. and the unavailability of data at STARTTLS should generate and immediate temporary failure to avoid other DOS conditions. Forwarded upstream. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387448: empty entropy pool leads to DOS
tags #387448 wontfix thanks Upstream has indicated that this is impossible to fix in exim. Please look in upstream's bugzilla, verify their arguments and take up the argument with them. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
