Re: [fetchmail-devel] timeout not working for TLS

[Matthias A. <mat...@gm...>]

Am 28.04.2011 17:06, schrieb Thomas Jarosch:
> On Thursday, 28. April 2011 14:42:21 Matthias Andree wrote:
>> $ sudo socat -dddD - tcp4-listen:110,reuseaddr
>> 1. paste +OK\n as greeting
>> 2. paste +OK\nSTLS\n.\n as response to STLS, then wait
> 
> Ok, I found the difference. If I wait at the same point as you do,
> the timeout is triggered. Please at step 3.:
> 
> 3. paste "+OK do it\n" and then wait

Got it, I can reproduce the problem.

> Some SSL garbage will appear in socat but that's fine.
> The strace output looks like this:
> 
> write(3, "STLS\r\n", 6)                 = 6 <0.000078>
> setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={90, 0}}, NULL) = 0 <0.000014>
> recv(3, "+OK do it\n", 512, MSG_PEEK)   = 10 <3.055521>
> read(3, "+OK do it\n", 10)              = 10 <0.000015>
> setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 <0.000012>

ouch.

> ...
> 
> -> The timeout get's disabled again. Any idea why?

I've analyzed it.  The trace in the Git master branch is:

(gdb) bt
#0  set_timeout (timeleft=0) at ../driver.c:100
#1  0x00000000004111a6 in gen_recv (sock=5, buf=0x7fffffff76d0 "+OK go\n",
    size=513) at ../transact.c:1575
#2  0x00000000004208c1 in pop3_ok (sock=0, argbuf=0x7fffffff7930 "STLS")
    at ../pop3.c:116
#3  0x0000000000410e56 in gen_transact (sock=5, fmt=0x42a0a2 "STLS")
    at ../transact.c:1632
#4  0x0000000000420ee4 in pop3_getauth (sock=5, ctl=0x4516d0,
    greeting=0x7fffffff9c30 "") at ../pop3.c:451

IOW, I had overlooked that gen_recv resets the timeout. We extract the
STLS response, which resets the timeout, thus the subsequent SSLOpen
isn't under some timeout.

Sorry for the incomplete fix in 6.3.18, and thanks for the report.  Now
I need to make sure I catch all similar bugs before releasing the next
version, and I need to update and re-issue the corresponding CVE (or a
new one, need to check with the gurus) and security announcement.

The fix needs a thorough analysis of the code.  Note that I've already
queued patches to ditch SSLv2 support, I need to reconsider that, or
making that an option so that distributors can go ahead and update their
6.3.ancient version to 6.3.20 without major incompatibilities.

I'll get back to this.

Thanks again -- I do appreciate bug reports that are easy to reproduce :-)

Best regards
Matthias