exim: privilege escalation

The main problem was that the MBX locking is following the specification for MBX locking (note: MBX not mbox, MBX is a much rarer thing). If you mount /tmp with symlinks disabled, you're safe. If your OS has O_NOFOLLOW support, then from 4.72 onwards, you're safe. If neither applies, 4.72 onwards works harder to detect the attack and bail out as early as possible if it's detected. Since Linux 2.1.126 onwards has this (per man-page, copied from FreeBSD), all modern Linux systems should be fine with 4.72.

The other issue is the hardlinks in /var/mail issue, since there are distributors who choose to make /var/mail be globally writable (with sticky-bit protection). Exim tries to be flexible but it turns out that when you try hard enough to shoot yourself in the foot, you can. With 4.72, Exim tries harder to keep you from shooting yourself in the foot. You're still far better off if you exercise more care in designing the permissions on /var/mail -- group mail and 1775 works fine, for instance -- then tools such as mutt_dotlock just need to be setgid mail, which they support.

It's unfortunate that these days many distributions have opted for one large filesystem for everything (so that regular users have files on the same filesystem as globally writable directories which are routinely accessed) and for lax permissions on the mail-spool. But that's life, software has to deal with it, and thanks to the report Exim now deals with these better. It's a shame that common standards have *regressed* in security here. 1775 directory with 0620 (group mail) mailboxes were around when I was starting on Unix.

[disclosure: I wrote the MBX patch and hack on Exim in my spare time]