IMAP Version < 4

CVE 1999-0005
CVE 1999-0042

Impact

Remote users can obtain root access on systems running a vulnerable IMAP server. Access to an account on the system is not needed to exploit this vulnerability.

Background

The current version of IMAP (Internet Message Access Protocol) supports both online and offline operation, permitting manipulation of remote message folders. It provides access to multiple mailboxes (possibly on multiple servers), and supports nested mailboxes as well as resynchronization with the server. The current version also provides a user with the ability to create, delete, and rename mailboxes.

POP (Post Office Protocol) was designed to support offline mail processing. That is, the client connects to the server to download mail that the server is holding for the client. The mail is deleted from the server and is handled offline (locally) on the client machine.

The Problem

In the implementation of both protocols on a UNIX system, the server must run with root privileges so it can access mail folders and undertake some file manipulation on behalf of the user logging in. After login, these privileges are discarded. However, in at least the University of Washington's implementation, a vulnerability exists in the way the login transaction is handled. This vulnerability can be exploited to gain privileged access on the server. By transmitting carefully crafted text to a system running a vulnerable version of these servers, remote users may be able to cause a buffer overflow and execute arbitrary instructions with root privileges.

Vulnerable versions of IMAP include the University of Washington implementations prior to IMAP4rev1 version 10.234, and all beta versions of IMAP4rev1.

Resolution

Telnet to port 143 on your server to find out what version of IMAP is running. Sites running vulnerable versions should install a patch from their vendor or upgrade to the latest version of IMAP.

Until you can take one of the above actions, temporarily disable the IMAP service. On many systems, you will need to edit the /etc/inetd.conf file. However, you should check your vendor's documentation because systems vary in file location and the exact changes required (for example, sending the inetd process a HUP signal or killing and restarting the daemon). If you are not able to temporarily disable the IMAP service, then you should at least limit access to the vulnerable services to machines in your local network. This can be done by installing TCP wrappers, not only for logging but also for access control. Note: Even with access control via TCP wrappers, you are still vulnerable to attacks from hosts that are allowed to connect to the vulnerable IMAP service.

Where can I read more about this?

Read more about this vulnerability in CERT Advisory 98.09. and CERT Advisory 97.09.