COMMAND

    imapd and ipop3d

SYSTEMS AFFECTED

    Any system running Mark Crispin's POP or IMAP server, of a release
    earlier than 4.1beta is vulnerable.

PROBLEM

    Following text is Secure Networks  Inc. (SNI) copyright and it  is
    part of their security advisory (March 2, 1997).

    A vulnerability exists within  Mark Crispin's mail server  toolkit
    that will  allow arbitrary  individuals to  obtain root  access to
    servers running imapd and  ipop3d.  This vulnerability  is present
    in  both  the  POP3  and  IMAP2bis  servers  included  in the PINE
    distribution, as well as  the IMAP2bis and IMAP4  servers included
    in Mr. Crispin's IMAP toolkit.

    The vulnerable  mail servers  call a  library routine  to affect a
    Unix "login",  authenticating the  user against  it's password.  A
    stack overrun exists in this  routine. In essence this will  allow
    any client with the ability to attempt a login to enter an  overly
    long username to cause arbitrary machine code to execute.

    Both  the  POP  and  IMAP  servers Mr. Crispin distributes discard
    supervisory privileges sometime  after this authentication  phase.
    Unfortunately, the  overflow occurs  before this  happens, and the
    vulnerability will thus allow an attacker superuser access.

    The problematic routine is server_login(), which is in "log_xxx.c"
    in the OS-dependent code  tree of the server  source distribution.
    The problem occurs  due to the  routine's attempt to  allow a case
    insensitive match on  the username, which  it does by  copying the
    username provided to the routine into an automatic variable in the
    routine's stack.

    The username  buffer is  MAILTMPLEN long,  which defaults  to 1024
    bytes.  Unfortunately, the  server's input buffer is  greater than
    this, allowing  a remote  client to  feed the  routine a  username
    greater  than  1024  bytes.   If  the  excess  characters  in this
    username contain a valid virtual memory address, the routine  will
    overwrite it's stack frame when copying the username, causing  the
    return from the routine to jump to an unexpected location.

    Interestingly, the  buffer is  converted to  lowercase after being
    copied.   This  provides  a  slight  technical  challenge,  as the
    machine code required to  take over the server  contains uppercase
    characters.   However,  modifications  to  the  "standard"   stack
    overrun exploit code  to reverse the  affects of this  lowercasing
    were  trivial.   On  i386  4.4BSD,  the  VM  address  required  to
    redirect  server_login()'s  return  need  not  contain   uppercase
    characters.

    The flawed code reads:

        long server_login (char *user, char *pass, int argc, char *argv[])
        {
            char tmp[MAILTMPLEN];
            struct passwd *pw = getpwnam (user);
                /* allow case-independent match */
            if(!pw) pw = getpwnam (lcase (strcpy (tmp, user)));

            <complete server login and return>
        }

    Remote individuals, who do not have a valid username and  password
    for the mail server, can  obtain root access to systems  running a
    vulnerable IMAP or POP server.

    Any system running Mark Crispin's POP or IMAP server, of a release
    earlier than  4.1beta is  vulnerable.   To determine  whether your
    system is vulnerable, telnet to ports  109, 110, 143 and 220.   If
    you see a banner looking like:

    * OK example.com IMAP2bis Service 7.8(92) at Mon, 3 Mar 1997 12:00:00 -0500 (EST)

    or:

    * OK example.com IMAP4 v10.00 server ready

    or:

    +OK example.com  POP3 3.0(10)  w/IMAP client  (Report problems  in
    this server to MRC@CAC.Washington.edu) at Mon, 3 Mar 1998 12:00:00
    -0500 (EST)

    Then  your  system  is  vulnerable.   If  you  see  "POP3  3.3" or
    "IMAP4rev1" or later, your POP or IMAP server is not vulnerable.

SOLUTION

    POP servers not  derived from Mark  Crispin's code, including  the
    somewhat  confusingly  named  "pop3d"   from  the  University   of
    California at Davis are not vulnerable to the attack described  in
    SNI advisory.  Similarly, the University of California at Berkeley
    popper, and  derived POP  servers, including  the Qualcomm popper,
    are not vulnerable to this attack.

    As  a  temporary  workaround,  you  can  disable  the POP and IMAP
    services in /etc/inetd.conf, and then kill and restart inetd.

    You can fix  the problem in  the source yourself,  by changing the
    server_login() function to read:

        char tmp[MAILTMPLEN];
        struct passwd *pw = getpwnam (user);

        if(!pw) {
            strncpy(tmp, user, MAILTMPLEN - 1);
            pw = getpwnam(lcase(tmp));

    Or,  as  a  final  option,  you  can  switch  to the IMAP 4.1 beta
    distribution, which can be found at:

        ftp://ftp.cac.washington.edu/mail/imap.tar.Z.

    Users of Red Hat  4.0 should apply the  Red Hat 4.1 fix.  Users of
    previous  releases  of  Red  Hat  Linux are strongly encouraged to
    upgrade  or  simply  not  run  imap.  You can remove imap from any
    machine running  with Red  Hat Linux  2.0 or  later by running the
    command "rpm -e imap", rendering them immune to this problem.

    All of the new packages are PGP signed with Red Hat's PGP key  (as
    is this message), and may be obtained from:

        ftp.redhat.com:/updates/4.1.

    If  you  have  any  questions  about  SNI  advisory,  feel free to
    contact author, by sending mail to davids@secnet.com.