[Dovecot] Re: worth a few Euros?

[Jared]

Don't worry about the "warning: exec file is newer than core file."  It 
only said that becuae I copied the binary to the dir after the core 
instead of having to keep typing the path to the real location of the 
binary.

Timo Sirainen wrote:
> 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.
> 
> 
>