Delivering MailUW IMAP

Delivering Mail ”UW IMAP

An MTA is only half of a mail server. Unless the server is also the client computer, or you plan to use local mail clients such as pine or elm, you need to provide delivery services for clients to access the stored mail spools. To handle delivery for messages received by the SMTP system, you can install the University of Washington's imapd (UW IMAP) software. This server can deliver to both POP and IMAP clients, and is simple to compile and install on Mac OS X.

Recent Exploits

Because your system doesn't come with UW IMAP installed, you need to install a version. Obviously you'll install the latest version, which (equally obviously) won't have any exploits at the time you download and install it. That, however, doesn't mean that its past has been squeaky clean; in fact, a number of exploits have affected the software in the past.

`AUTHENTICATE` buffer overflow

The UW IMAP server has been subject to a number of buffer overflow problems. One of the most notable was the AUTHENTICATE command overflow. Used during the login process, IMAP's AUTHENTICATE command is used to specify the authentication method that the IMAP client uses. When the buffer for AUTHENTICATE suffers a specific overrun , it allows remote attackers to send arbitrary machine code to the server, which would then be executed. Previously, a similar exploit had been found that functioned in much the same way, but was accessed through the LOGIN IMAP function.

These exploits are extremely serious because the server process executes with root permissions, and the "injected" exploit code runs as part of the already active process, making it difficult to detect. One positive note is that the existing exploit code is (as expected) x86-centric. This isn't saying that the exploit isn't possible on the PPC architecture, but rather that it would need to be reworked to affect an early IMAP server running on Mac OS X. For more information, visit http://www.yale.edu/its/security/archive/unix- sysadmins -security/9807/msg00008.html.

Other Buffer Overflows

The last reported remote root exploit for UW IMAP was in the late 90s. Unfortunately, since that time, several other buffer overflows have been reported to (or by) the authors, as late as mid-2001. These are not root exploits, yet still pose a risk of allowing remote users to execute code on the affected server. For more information, see http://online.securityfocus.com/archive/1/190251.

IMAP and POP Protocol Exploits

Unfortunately, even with a perfectly healthy UW IMAP, your mail server is far from secure. As you've learned repeatedly throughout the book, many common TCP/IP protocols are insecure and open for sniffing. Web, FTP, and Mail protocols make up a large portion of the Internet's traffic. None of these, in their default states, offer any sort of protection from a network sniffer.

For example, POP-based email is the most popular form of mail delivery online. Yet the exchange of username and password isn't protected at all:

 %  telnet mail.mac.com 110  Trying 204.179.120.64... Connected to mail.mac.com. Escape character is '^]'. +OK Netscape Messaging Multiplexor ready  USER johnray  +OK password required for user johnray  PASS Gringle121  +OK Maildrop ready

In this sample POP connection with mail.mac.com , I connect to port 110, provide my username and password in clear text, and I'm logged in. Similarly, IMAP servers also support cleartext passwords:

 %  telnet mail.mac.com 143  Trying 204.179.120.64... Connected to mail.mac.com. Escape character is '^]'. * OK Netscape Messaging Multiplexor ready  00001 login johnray Gringle121  00001 OK User logged in

Sniffing this information on mac.com compromises my email. Sniffing a username and password on your server's email potentially compromises your account ”and presumably you have root privileges.

One might think, "Eh, so what?" Who is going to sit around all day and watch network traffic waiting to see a username and a password? The answer is no one .

Instead, they'll use one of dozens (or perhaps dozens of dozens) of available network sniffers that are programmed with basic knowledge of common protocols and can simply watch for username/password pairs and record them to a file. One such software package, available for Mac OS X, is ettercap (http://ettercap. sourceforge .net/). You'll learn more about this in Chapter 7, "Eavesdropping and Snooping for Information: Sniffers and Scanners." For now, understand that the basic mail protocols are not secure. Not without some additional help.

SSL and UW IMAP

To eliminate some of the threat of sniffing account passwords directly from IMAP and POP traffic, you can create the SSL-wrapped equivalents of these services by using OpenSSL. SSL (Secure Sockets Layer) protects against sniffing by encrypting all traffic moving across the network. Developed by Netscape for use on the Web, SSL has been adopted as an industry standard for encrypting a number of protocols ”in this case, IMAP and POP. For an easy-to-understand introduction to SSL, visit http://developer.netscape.com/docs/manuals/security/sslin/contents.htm.

Outlook, Entourage, and Mac OS X's Mail application all support SSL-encrypted mail traffic natively ”just check an SSL check box. You can find this option by clicking the Options button in the Account Information tab within account preferences in Mac OS X's Mail, as seen in Figure 13.2.

Figure 13.2. SSL is supported natively in Mac OS X's Mail.app.

graphics/13fig02.jpg

The SSL-enabled versions of IMAP and POP are referred to as IMAPS and POPS, and operate by using TCP from ports 993 and 995, respectively. Conveniently, these services (and their nonencrypted counterparts) are already listed in Mac OS X's /etc/services file, so you're ready to configure and install UW IMAP.

Compiling and Installing

Installation and setup of your IMAPS/POPS server is fast and painless. Fetch the latest version of UW IMAP from the University of Washington's FTP site, ftp://ftp.cac.washington.edu/imap/.

Uncompress and unarchive the imap.tar.gz file, then cd into the source directory:

 $  tar zxf imap-2002.DEV.SNAP-0205.tar.gz   $ cd imap-2002.DEV.SNAP-0205032002

Before compiling, you need to make a few important changes to the source code. Unfortunately, UW IMAP is not very "user-friendly" for setting up, so you need to do all configuration by editing the src/osdep/unix/env_unix.c file. This isn't difficult, but is atypical for most modern Unix software distributions.

Open the env_unix.c file in your favorite text editor now.

Look for the line reading

 static char *mailsubdir = NIL;  /* mail subdirectory name */

and change it to

 static char *mailsubdir = "Library/Mail/Mailboxes";  /* mail subdir name */

This sets the IMAP server to use your account's standard Mailboxes directory for storing IMAP mailboxes.

Now it's compile time. Make sure that you're within the root level of the UW IMAP distribution. Because you want to compile for Mac OS X with SSL support built in, you need to provide two options to the make command: osx and SSLTYPE=unix :

[View full width]

  [View full width] 
 %  make osx SSLTYPE=unix  Applying an process to sources... tools/an "ln -s" src/c-client c-client tools/an "ln -s" src/ansilib c-client tools/an "ln -s" src/charset c-client tools/an "ln -s" src/osdep/unix c-client tools/an "ln -s" src/mtest mtest tools/an "ln -s" src/ipopd ipopd tools/an "ln -s" src/imapd imapd ln -s tools/an . make build EXTRACFLAGS='' EXTRALDFLAGS='' EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS=''  PASSWDTYPE=std SSLTYPE=unix EXTRASPECIALS='' BUILDTYPE=osx ...

Following the compile, the server binaries will be stored in imapd/imapd and popd/ipop3d . You should copy these to /usr/local/libexec :

 #  cp popd/ipop3d /usr/local/libexec   # cp imapd/imapd /usr/local/libexec

WU IMAP is now installed, but you still need to make a few more configuration changes for the inetd/xinetd .

Launching Through `inetd` / `xinetd`

Chapter 11 provided detailed information on setting up services to run under inetd and xinetd . Because you have an entire chapter dedicated to this, we won't be providing the complete instructions. Table 13.10 contains the parameters you need for setting up the services with either of these Internet daemons.

Table 13.10. Parameters for Configuring `inetd` or `xinetd`

Service Name	Socket Type	Protocol	wait / nowait	User	Server Process	Arguments
`imaps`	`stream`	`tcp`	`nowait`	`root`	`/usr/libexec/tcpd`	`/usr/local/libexec/imapd`
`pops`	`stream`	`tcp`	`nowait`	`root`	`/usr/libexec/tcpd`	`/usr/local/libexec/ipop3d`

NOTE

This assumes that you'll also want to use TCP Wrappers with the IMAPS and POPS services, which isn't necessary under xinetd . Keep in mind that you need to add similar entries for IMAPS/POP if you want to run cleartext versions of the services.

In addition, there is no need to provide access to both IMAPS and POPS unless required by your users. If you don't need one or the other, don't add it.

Creating a Certificate

The IMAPS and POPS services require two certificates be installed: imapd.pem and ipop3d.pem . We're going to look at creating self-signed certificates. Production servers should consider purchasing certificates from a qualified CA.

For the IMAPS server, issue the following command at a shell prompt:

 #  openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 3650

This creates a new self-signed certificate named imapd.pem with a 10-year expiration within the current directory. You should also create a ipop3d.pem certificate if adding support for POPS. Both of these certificates must then be copied or moved to /System/Library/OpenSSL/certs or /usr/local/ssl/certs if you're using a fresh install of OpenSSL.

 #  cp *.pem /System/Library/OpenSSL/certs

If you haven't created a certificate with openssl before, the following is a sample of the questions you will be asked during setup. For your mail server, the critical piece of information is the Common Name. This value should be set to the hostname to which users will connect when using their email clients. In this example, I've chosen to use the IP address 10.0.1.101 . If I were using this certificate with real clients, they would need to connect to the mail server based on this IP address.

 Generating a 1024 bit RSA private key .........++++++ ...................................................................++++++ writing new private key to 'imapd.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank. For some fields there will be a default value. If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:  US  State or Province Name (full name) [Some-State]:  OH  Locality Name (eg, city) []:  Dublin  Organization Name (eg, company) [Internet Widgits Pty Ltd]:  Poisontooth  Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:  10.0.1.101  Email Address []:

After you've created the certificates and configured the Internet daemon entries, you can restart inetd/xinetd to start using UW IMAP ( kill -HUP <process ID> ). The server should be ready for use.

Be sure that you configure your email clients to use SSL or they won't be able to connect (unless you've also added support for straight imap and pop ).

Top