Bug#343085: exim4: Exim SMTP_AUTH hangs since today...

[Sven Hartge]

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: sven at svenhartge.de