Florian Weimer wrote: > * Sven Hartge: >> Florian Weimer wrote: >>> * Florian Weimer:
>>>> It's the generation of the special server-side key used to >>>> support "RSA export" clients which use 40-bit symmetric session >>>> keys. >>> Turns out the patch was broken. This one should be better. The >>> comments above still apply. >> Will this patch be included in the next point release of Sarge > > Not sure about that. There are different means to to tackle this > problem. We could just remove > > rm -f /var/spool/exim4/gnutls-params > > from the daily cron job. Or we add proper locking so that only one > Exim process actually recomputes the params file when it is missing, > significantly reducing the impact of this problem. Or the preferred > option: do not remove that file, but regenerate it and replace it > with the new version, so that Exim never has to regenerate it. Isn't this what is done in the version from Sid right now? > In any case, we need people whose Exim installations suffer from this > problem to test a patch before we roll it out. I am more going to test this patch as soon as possible, probably this evening. >> or better yet released via a security update, since it is trivial >> to DoS Exim4 from Sarge with some single SSL/TLS connections? > > AFAICS, it is not possible to trigger this bug reliably (I had to > delete the params file manually to prove it). I don't have to delete the params file, as _every single_ encrypted mail transaction totally depletes my entropy pool, thus it is impossible for my server to receive more than 1 mail every 5 minutes without totally stalling. So if you wanted to DoS my server, you just had to open some SSL connections and *whoop*, no more mail delivery or reception is possible, since the entropy pool stays at a constant zero, if you reopen a new connection from time to time. With exim+openssl I am not able to reproduce this effect and I have yet to test your patch to see if it also solves the problem. > It certainly results in a loss of service, but it's a security > vulnerability, and therefore does not qualify as a security bug. You probably mean "it's not a security vulnerability" in which case I object. Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ Achtung, neue Mail-Adresse: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]