On 28.1.2006 21:33, "-- --" <demottjar@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@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@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@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@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.