Buffer overflow in Dovecot or OpenSSL?

[Timo Sirainen <tss () iki fi>]

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/*.