Buffer overflow in Dovecot or OpenSSL?

From: Timo Sirainen (tssat_private)
Date: Tue Apr 08 2003 - 12:39:23 PDT

  • Next message: Timo Sirainen: "Re: Buffer overflow in Dovecot or OpenSSL?"

    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 : Tue Apr 08 2003 - 14:31:42 PDT