[Dovecot] worth a few Euros?

[Timo Sirainen]

On 28.1.2006 21:33, "-- --" <demottjar at yahoo.com> wrote:

> Yo Timo, did you say that login processes "just don't
> crash"?  Found these while doing load/malformed data
> tests.  Got the kernel patch allow_setid_cores
> working.  Don't have time to check if they're
> exploitable.  Probably time to get a gamma version out
> for people, eh?

Any suggestions how I could reproduce these myself? I have this one simple
stress test tool myself, but I couldn't get it to cause any crashes.

> related.  Be sure to check
> if a pointer is valid and that will get rid of most of
> these.

That won't help. If any of these crashes happen, the memory is already
corrupted and there's no point in trying to avoid crashing.

> Note: I have plenty of sample cores if you need one to
> fix.

Those could be helpful, but I'll also need the exact same binaries that
produced them.

> [root at server dovecot]# gdb ./dovecot-auth -c
..
> #0  auth_request_unref (_request=0x807b0f0) at
> auth-request.c:96

This happened if client did an "AUTHENTICATE" command and then disconnected.
Got broken with the large changes I did for beta1 (void pointers are evil).
Not exploitable, always crashes while trying to dereference 0x1 pointer.
Fixed in CVS.

> [root at server 1]# gdb ./dovecot-auth -c core.30100
..
> warning: exec file is newer than core file.

So this didn't help, as the core file must be used against the same binary
or everything will just show garbage. But I'd guess it's the same problem as
above.

> [root at server login]# gdb ./imap-login -c core.25116
..
> #0  i_stream_read (stream=0x0) at istream.c:48
> 48              if (stream->closed)
> (gdb)  bt
> #0  i_stream_read (stream=0x0) at istream.c:48
> #1  0x0804ade2 in client_read (client=0x8070410) at
> client.c:311
> #2  0x0804ae3c in client_input (context=0x8070410) at
> client.c:333

Hmm. Have to look into this. Looking at the code, it seems that client
structure was unreferenced too many times, but client_destroy() was never
called.

The reference counting code in authentication is pretty horrible. Guess I'll
have to clean it up.

> [root at server core]# gdb ./imap -c core.15043
..
> warning: exec file is newer than core file.

Again this problem, so I don't know how much I can rely on this backtrace.

> #1  0x42028a73 in abort () from /lib/tls/libc.so.6
> #2  0x0809f9fc in i_internal_panic_handler
> (fmt=0x80ac360 "file %s: line %d (%s): assertion
> failed: (%s)",
>     args=0xbfffdd94 "\0251\v\b?") at failures.c:375
> #3  0x0809f5cb in i_panic (format=0x80ac360 "file %s:
> line %d (%s): assertion failed: (%s)") at
> failures.c:173
> #4  0x08082277 in mail_cache_transaction_reserve_more
> (ctx=0x80cb4a0, block_size=332, commit=true)
>     at mail-cache-transaction.c:257

There's no assert call in line 257. The closest one is at line 252, but I
couldn't see how it could happen. I did some cleaning up for that code now,
but I didn't do any changes for the logic itself.