Summary: Solaris and Linux file system behavior has changed over time, breaking one of the assumptions in Postfix. See below for a description of the behavior and how it disagrees with standards. Postfix is not affected on systems with standard (POSIX, X/Open) file system behavior, i.e. *BSD, AIX, MacOS, HP-UX, and very old Sun/Linux systems. The fix and workarounds are simple. There are efforts to get the non-standard behavior approved by standards (a function called llink). Today's fix for Solaris, Linux etc. also makes Postfix future-proof for such changes. Wietse 1. Postfix local privilege escalation via hardlinked symlinks ============================================================= Sebastian Krahmer of SuSE has found a privilege escalation problem. On some systems an attacker can hardlink a root-owned symlink to for example /var/mail, and cause Postfix to append mail to existing files that are owned by root or non-root accounts. This can happen on operating systems with specific non-standard behavior. Symlinks (symbolic links) implement aliasing for UNIX pathnames. They were introduced with 4.2BSD UNIX in 1983, and were adopted by other UNIX systems in the course of time. Hardlinks are older and implement the primary mechanism for accessing file system objects. In some UNIX systems, the link(symlink, newpath) operation has changed over time: instead of recursively following the symlink and creating a hardlink to the file thus found, it creates a hardlink to the symlink itself. This behavior disagrees with, for example, the POSIX.1-2001 and X/Open XPG4v2 standards, and is the default on current Solaris, IRIX and Linux systems. On systems with this non-standard behavior, Postfix may be vulnerable depending on how it is configured. Postfix allows a root-owned symlink as a local mail destination, so that mail can be delivered to e.g. /dev/null which is a symlink on Solaris. 2. What configurations are (not) affected ========================================= A configuration is considered affected when an attacker with local access to a system can make Postfix append mail to an existing file of a different user. Appendix A gives a procedure to determine if a system is affected. The following configurations are NOT affected: Postfix on FreeBSD 7.0, OpenBSD 4.3, NetBSD 4.0, MacOS X 10.5, AIX 5.3, HP-UX 11.11, Solaris 1.x, Linux kernel 1.2.13, and other systems with standard hardlink behavior. However, these systems may become affected when they share file systems with hosts where users can create hardlinks to symlinks. Also not affected are the following configurations: a) maildir-style delivery with the Postfix built-in local or virtual delivery agents; b) mail delivery with non-Postfix local or virtual delivery agents; c) mailbox-style delivery with the Postfix built-in virtual delivery agent when virtual mailbox parent directories have no "group" or other write permissions. The following configurations are known to be affected on Linux kernel >= 2.0, Solaris >= 2.0, OpenSolaris 11-2008.5, IRIX 6.5, and other systems where users can create hardlinks to symlinks: a) mailbox-style delivery with the Postfix built-in local delivery agent; b) mailbox-style delivery with the Postfix built-in virtual delivery agent when virtual mailbox parent directories have "group" or other write permissions. 3. Solution =========== If your system is affected, upgrade Postfix, apply the patch in Appendix C, or apply one of the countermeasures in section 4. Updated versions will be made available via http://www.postfix.org/ for Postfix versions 2.3, 2.4, 2.5, and 2.6. Individual vendors will provide updates depending on their support policy. 4. Countermeasures ================== Each of the following countermeasures will prevent privilege escalation through Postfix via hardlinked symlinks: 1) Protect mailbox files (maildir files are not affected). The script in Appendix B makes sure that the system mail spool directory is owned by root, that the sticky bit is turned on, and that each UNIX account has a mailbox file; it also has suggestions for virtual mailbox file deliveries (again, maildir files are not affected). 2) Don't allow non-root users to create hardlinks to objects of other users. This behavior is configurable on some systems. Appendix A: Procedure to find out if a system is affected ========================================================= As mentioned in section 2, not affected are maildir-style delivery with the Postfix built-in local or virtual delivery agents, mail delivery with non-Postfix local or virtual delivery agents, and mailbox-style delivery with the built-in Postfix virtual delivery agent when virtual mailbox parent directories have no "group" or other write permissions. To find out if a system may be affected, execute the following commands as non-root user on a local file system: $ PATH=/bin:/usr/bin:$PATH $ mkdir test $ cd test $ touch src $ ln -s src dst1 $ ln dst1 dst2 $ ls -l For the test to be valid, all commands should complete without error. The system is NOT affected when "ls -l" output shows one symlink (dst1 -> src) and two files (dst2, src) as in example A.1. Example A.1: lrwxr-xr-x 1 user users 3 Mmm dd hh:mm dst1 -> src -rw-r--r-- 2 user users 0 Mmm dd hh:mm dst2 -rw-r--r-- 2 user users 0 Mmm dd hh:mm src However, the system may become affected when it shares file systems with hosts where users can create hardlinks to symlinks as described next. The system is affected when "ls -l" output shows two symlinks and one file as in example A.2, with the following Postfix configurations: a) mailbox-style delivery with the Postfix built-in local delivery agent; b) mailbox-style delivery with the Postfix built-in virtual delivery agent when virtual mailbox parent directories have "group" or other write permission. Example A.2: lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst1 -> src lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst2 -> src -rw-r--r-- 1 user users 0 Mmm dd hh:mm src Appendix B: Procedure to protect mailbox files ============================================== This section describes one of the countermeasures (see section 4) that eliminate the problem without updating Postfix. The Perl script below hardens systems that use mailbox-style deliveries with the Postfix built-in local delivery agent; it makes sure that the system mailspool directory is root-owned and sticky, and that every UNIX account has a mailbox file. The script assumes that mailbox files are stored under /var/mail. Similar actions would be needed for systems that use mailbox-style delivery with the Postfix built-in virtual delivery agent, but this is needed only when Postfix virtual mailbox parent directories have "group" or other write permissions. Unfortunately, an automated script for this cannot be made available due to the large variation between Postfix configurations. #!/usr/bin/perl # fix-mailspool - Make sure the mailspool directory is root-owned # and sticky, and that every UNIX account has a mailbox file. use Fcntl; $debug = 0; # Follow compatibility symlink. $mailspool="/var/mail/"; chown(0, -1, $mailspool) || die("can't set root ownership for $mailspool: $!\n"); chmod((stat($mailspool))[2] | 01000, $mailspool) || die("can't set sticky bit for $mailspool: $!\n"); while(($name, $passwd, $uid, $gid, $quota, $comment, $gcos, $dir, $shell) = getpwent()) { print "user $name\n" if $debug; $mailbox = ($mailspool . $name); if (! -e $mailbox) { print "create $mailbox\n" if $debug; if (!sysopen(MAILBOX, $mailbox, (O_CREAT | O_RDWR | O_EXCL), 0600)) { warn("can't create $mailbox: $!\n"); } else { # XXX fchown() is not portable. chown($uid, $gid, $mailbox) || warn("chown $mailbox: $!\n"); close(MAILBOX); } } elsif (! -f $mailbox) { warn("$mailbox is not a regular file\n"); } elsif ((stat($mailbox))[4] != $uid) { warn("$mailbox is not owned by $name\n"); } } Appendix C: Source code patch ============================= This patch is suitable for Postfix 2.0 and later. It presents the least invasive change that eliminates the problem. Future Postfix releases may adopt a different strategy. The solution introduces the following change: when the target of mail delivery is a symlink, the parent directory of that symlink must now be writable by root only (in addition to the already existing requirement that the symlink itself is owned by root). This change will break legitimate configurations that deliver mail to a symbolic link in a directory with less restrictive permissions. *** src/util/safe_open.c.orig Sun Jun 4 19:04:49 2006 --- src/util/safe_open.c Mon Aug 4 16:47:18 2008 *************** *** 83,88 **** --- 83,89 ---- #include <msg.h> #include <vstream.h> #include <vstring.h> + #include <stringops.h> #include <safe_open.h> /* safe_open_exist - open existing file */ *************** *** 138,150 **** * for symlinks owned by root. NEVER, NEVER, make exceptions for symlinks * owned by a non-root user. This would open a security hole when * delivering mail to a world-writable mailbox directory. */ else if (lstat(path, &lstat_st) < 0) { vstring_sprintf(why, "file status changed unexpectedly: %m"); errno = EPERM; } else if (S_ISLNK(lstat_st.st_mode)) { ! if (lstat_st.st_uid == 0) ! return (fp); vstring_sprintf(why, "file is a symbolic link"); errno = EPERM; } else if (fstat_st->st_dev != lstat_st.st_dev --- 139,167 ---- * for symlinks owned by root. NEVER, NEVER, make exceptions for symlinks * owned by a non-root user. This would open a security hole when * delivering mail to a world-writable mailbox directory. + * + * Sebastian Krahmer of SuSE brought to my attention that some systems have + * changed their semantics of link(symlink, newpath), such that the + * result is a hardlink to the symlink. For this reason, we now also + * require that the symlink's parent directory is writable only by root. */ else if (lstat(path, &lstat_st) < 0) { vstring_sprintf(why, "file status changed unexpectedly: %m"); errno = EPERM; } else if (S_ISLNK(lstat_st.st_mode)) { ! if (lstat_st.st_uid == 0) { ! VSTRING *parent_buf = vstring_alloc(100); ! const char *parent_path = sane_dirname(parent_buf, path); ! struct stat parent_st; ! int parent_ok; ! ! parent_ok = (stat(parent_path, &parent_st) == 0 /* not lstat */ ! && parent_st.st_uid == 0 ! && (parent_st.st_mode & (S_IWGRP | S_IWOTH)) == 0); ! vstring_free(parent_buf); ! if (parent_ok) ! return (fp); ! } vstring_sprintf(why, "file is a symbolic link"); errno = EPERM; } else if (fstat_st->st_dev != lstat_st.st_dev