exim: privilege escalation

Posted Jun 13, 2010 23:24 UTC (Sun) by Comet (subscriber, #11646)
In reply to: exim: privilege escalation by nix
Parent article: 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]

exim: privilege escalation

Posted Jun 14, 2010 20:10 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

I hasten to add that I wasn't snarking at you: I was snarking at those who were claiming in another thread that measures against /tmp symlink attacks weren't necessary because the thing to do is fix the broken software. If even *MTAs* make this mistake, then so does everyone.

(And, MBX, gods that brings back memories. I haven't had to deal with that in, what, fifteen years?)

exim: privilege escalation

Posted Jun 14, 2010 22:07 UTC (Mon) by Comet (subscriber, #11646) [Link] (3 responses)

How about: If your software relies on being able to use symlinks in /tmp, then the thing to do is to fix your broken software so that it runs on sane systems where /tmp is mounted nosymfollow. :-)

-Phil, who prefers to fix things comprehensively rather than have security dependent upon the weakest link.

exim: privilege escalation

Posted Jun 14, 2010 23:26 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Well, yes, that too: but this attack relies on getting things to follow symlinks in /tmp when they think they're *not*. I suspect that fairly often the authors of such software barely know what symlinks are.

(btw, 'hack on Exim in my spare time' must be perhaps the most self-deprecating self-description I've ever heard from the founder of any major free software project, assuming I've managed to identify the original author of MBX support back in 199x correctly: the version control logs don't go back that far that I can find. But then, nobody does self-deprecation like cam.ac.uk. ;} )

exim: privilege escalation

Posted Jun 14, 2010 23:42 UTC (Mon) by Comet (subscriber, #11646) [Link] (1 responses)

Wrong Phil. I'm not the original author, he's retired. There's too many Phil's around. Haven't yet come up with a workable patch or workaround for that.

He's "PH/nn" in the changelogs, I'm "PP/nn". And no urinary jokes please. :)

exim: privilege escalation

Posted Jun 15, 2010 6:54 UTC (Tue) by nix (subscriber, #2304) [Link]

Ah. I misread the changelogs: one of the Other Phil's changes was right above yours and another right below :)

(the Phil Conspiracy?)