The IBM Secure Mailer, also known as Postfix, provides a mode-1777 directory for users to drop off queue files. All incoming and outgoing messages pass through this mechanism. This deliberate design decision leads to four obvious security holes, of varying levels of applicability and severity, as described here. The nastiest one is #2: selective anonymous message destruction. 1. Anonymous snooping SECURITY HOLE: Any local user can stat() files in the IBM Secure Mailer drop directory. IMPACT: Any local user can anonymously inspect the uids and sizes of new messages. It doesn't matter how well the system administrator has protected his process list, mail logs, and message transport mechanisms; private information is freely available in the IBM Secure Mailer queue. One might naively respond that queued messages are visible for only a moment. However, the attacker can drastically slow down the IBM Secure Mailer (for example, by creating thousands of temporary files in the drop directory) to give himself ample time to look for queued messages. Making the drop directory unreadable does not stop this attack, or even slow it down perceptibly. Queue file names are easy to predict. 2. Anonymous message destruction SECURITY HOLE: Any local user can make hard links to files in the IBM Secure Mailer drop directory. IMPACT: Under the IBM Secure Mailer, any local user can anonymously eliminate selected messages from the mail queue. It is impossible to identify the culprit after the fact. There are several ways to carry out this attack. The attacker can, for example, create a temporary directory under a weird name inside the drop directory, and link the victim's message file to a new name inside the temporary directory. The IBM Secure Mailer will then remove the original name because it has too many links. The attacker can then remove the new link and the temporary directory. It is easy to avoid detection. Wietse Venema, author of the IBM Secure Mailer, claims that the mail will be delivered. That is false. I invite other security experts to verify and publicly confirm that the IBM Secure Mailer allows message destruction by local users. Venema also claims that standard UNIX accounting facilities can be used to expose the culprit. That is false. UNIX accounting keeps track of which users were running programs and for how long; it does not reveal what those programs were doing. 3. Anonymous mailbombing SECURITY HOLE: On (uncommon but still extant) UNIX variants that allow file giveaways, any local user can create files in the IBM Secure Mailer drop directory owned by another user. IMPACT: On UNIX variants that allow file giveaways, any local user can use the IBM Secure Mailer to send mail that is logged as another user. This dodges mail accounting; it can be used to send anonymous mailbombs. It is impossible to identify the culprit after the fact. Other MTAs are careful to record the source of each local message. They also attempt to record the source of remote messages, specifically the IP address and optional extra information supplied by the remote host; there are still some security holes here that permit anonymous mail (and mail destruction!), but all of those flaws will eventually be fixed by cryptographic techniques. 4. File theft SECURITY HOLE: Any local user can make hard links into the IBM Secure Mailer drop directory from files visible elsewhere in the filesystem. IMPACT: An attacker can force the IBM Secure Mailer to send a victim's file as a mail message, under the following conditions: the file has mode 700; it is in a world-readable directory on the right filesystem; it happens to have the right structure for an outgoing mail message; and it is removed by the victim. Venema claims that the file will not be delivered. That is false. There are, as above, several ways for the attacker to put the victim's file into the IBM Secure Mailer drop directory with the correct name and link count after the file is removed by the victim. Venema also responds that queue files have ``a very specific file format that is produced by no other software.'' No evidence is presented for this bold claim. There are obvious examples of files whose contents are partly private, making theft a serious problem, and partly under control of an attacker; what happens if a UNIX mbox is fed through the standard UNIX split utility, changed to mode 700 for transport, and then removed? I don't plan to engage in further evaluation of the applicability of this security hole. I consider it unacceptable that some file formats can be mailed without the owner's consent. 5. Technical notes The standard solution to linking problems in the security community is to avoid world-writable directories. For example, if a user puts temporary files into $HOME/tmp, and there are no world-writable directories on the $HOME filesystem, then there's no place for an attacker to put an anonymous hard link. (I think that link() should be prohibited for anyone except the file owner. Unfortunately, that's not how UNIX works today.) Why doesn't the IBM Secure Mailer use a protected queue, and a setuid program to add mail to the queue with guaranteed user identification? The documentation claims that this is a security feature! ``No Postfix program is set-uid,'' it says. ``Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid) causes more trouble than it is worth.'' Certainly setuid programs require a great deal of care. They've been involved in many security disasters, though far fewer than (for example) world-writable directories. The security community would love to see another portable IPC mechanism offering guaranteed user identification. (I suggest that kernels add a getpeeruid() system call, showing the real uid that called connect(), for UNIX-domain sockets and for loopback TCP sockets.) However, while we're waiting, we need a few setuid programs. 6. Historical notes All of the problems described here are obvious from a glance at the IBM Secure Mailer documentation. Apparently I was the first to point them out (privately on Thursday, and then publicly on Sunday, in a discussion of basic security design), but I don't claim any credit for this. Venema's immediate reaction was outright denial. ``Bernstein is wrong on all points,'' he said in a public statement in response to a summary of my comments. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' Venema continued by giving an example of how an incompetent intruder might fail to destroy a file. Venema then sent a message titled ``Claimed Postfix Vulnerabilities'' to bugtraq. ``In my opinion, no-one has brought forward a vulnerability worth mentioning,'' he said. He began by talking about some of the spam-friendly defaults in the IBM Secure Mailer, and then continued with a horrendously inaccurate summary of the world-writability problems. I have one question for Venema: did he honestly believe at that point that there was no security hole? In any case, he owes an apology to me, and to the users of the IBM Secure Mailer. ---Dan
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:35 PDT