From: Admin (adminwww.dragonlance.eu.org)
Date: Wed Apr 09 2003 - 02:51:24 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I doesn't know a lot PAX, but if work like openwall the system have the
core file as a normal crashed program. You can backtrace this file:
gdb normal_file corefile
after that type: bt
the first line is the latest function executed...
with: i r
you will have the register informations...

Timo Sirainen wrote:
> I saw a disturbing message today:
>
> PAX: terminating task: /usr/local/libexec/dovecot/imap-login(imap-login):13964, uid/euid: 102/102, EIP: 5D0CB8B8, ESP: 5D0CB82C
> PAX: bytes at EIP: d8 b8 0c 5d 25 14 05 08 f8 9e 06 08 01 00 00 00 20 ca 04 08
>
> It's grsecurity patched Linux kernel with non-exec stack/heap and
> randomized stack/mmap base addresses. Stack seems to be always
> randomized at 5xxxxxxx, so ESP looks valid. Those bytes didn't seem to
> contain valid x86 code.
>
> Because EIP is so close to ESP, I can't think of any other way to cause
> this than overflowing a buffer in stack so that function return address
> is taken from some existing pointer in stack.
>
> imap-login process does two things: First it accepts a IMAP client
> connection and handles it until user is logged in or disconnects. Once
> logged in, the fd is passed to another process via UNIX sockets. It also
> acts as SSL proxy for the entire lifetime of the connection (because it
> runs as chrooted non-privileged user).
>
> So either the bug is in Dovecot, or it's in OpenSSL (or glibc). I've
> checked the imap-login code a few times now and I can't find anything
> where this could possibly happen, especially because there's almost no
> buffers stored in stack. But it's my code, so maybe I'm overlooking
> something.
>
> So the alternative is OpenSSL. Could there still be buffer overflow
> lying in there? I'm not familiar with OpenSSL code, and I don't really
> have time to start auditing it now. I'm running Debian unstable's
> 0.9.7a-1 version.
>
> Annoying thing is that I'm not sure if this was some cracking attempt,
> or if it was simply some bug that got triggered the first time. I wasn't
> logging network traffic, and all IMAP logins are logged only by the
> imap-login process after user has either logged in or closed connection.
> (I'll fix it to make sure the IP is always logged)
>
> This happened only once, two seconds after a user had logged in with
> Outlook Express 6 and almost instantly closed it, so it does suggest
> that the problem is with SSL handling.. or maybe just good timing. The
> same binary has been in use for 11 days now without any other problems
> and I couldn't find anything strange from logs either.
>
> If anyone wants to look at the imap-login, the sources are at
> http://dovecot.procontrol.fi/test/ (SSL proxy was rewritten since last
> release). The imap-login code is in login-common/*, imap-login/*,
> lib-imap/imap-parser.* and lib/*.
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]