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/*. > > >
This archive was generated by hypermail 2b30 : Wed Apr 09 2003 - 08:03:41 PDT