Bugzilla – Bug 989
CVE-2010-2024 - MBX locking race condition
Last modified: 2011-05-19 12:37:45 UTC
Created attachment 387 [details] Patch for this issue and the one in #988 [Copied from original notification email] 2. When MBX locking is enabled, local users may exploit a race condition to change permissions of other non-root users' files, leading to denial-of-service conditions or potentially privilege escalation, or to create new files owned by other users in The second issue is resolved by first attempting to open the file without O_CREAT. If it succeeds, then we use fstat() to check that the file is not a symlink, etc. If the open doesn't succeed, then we make another attempt using O_CREAT | O_EXCL. If this fails, something fishy is going on. Otherwise, we obtain a safe lock file. Let me know if you have any questions about these issues, or have any problems with the patch. Even though neither of these two vulnerabilities affects many downstream distributions by default (since sticky-bit mail directories are becoming more rare and MBX locking isn't used by many distributions), I'd like to publish an advisory for these issues independently once you have released a fix. I'd appreciate it if you kept me posted on any progress in regards to these issues. [...] I'll walk through an example of exploitation of the second vulnerability. Say attacker "bar" is delivering mail to user "foo". At src/transports/appendfile.c, line 2008, Ulstat() is called to both check the existence of a lockfile and whether or not it's a symlink or hard link. Suppose there is no lockfile at this point. After the Ulstat() call (but before subsequent calls), the attacker can create a symlink to a non-existent file in a directory foo has permission to write to, and the subsequent Uopen() call will create that file for the attacker because of the O_CREAT flag. In other cases, the attacker can instead create a symlink to an already existing file owned by "foo", and the subsequent Uchmod will change the permissions of the file pointed to by the symlink. In short, it's the space between the Ulstat() call and either the Uopen() or Uchmod() calls that causes the exploitable race condition. In practice, these sorts of things are usually exploited by rapidly creating and deleting a symlink in /tmp while repeatedly executing the vulnerable program. I do understand why my proposed fix is unacceptable from a locking standpoint, so of course feel free to disregard that part of the patch. Hopefully this clarifies these issues - let me know if anything's still fuzzy.
[Comments from Phil Pennock] The second is a symlink attack against /tmp -- so if you're on a sane system which inhibits following symlinks in /tmp then you're protected. Eg, BSD 'nosymfollow' option on the mountpoint. The exposure is that an empty file can be created as the attacked user, or an fcntl exclusive lock can be taken out against an existing file. Mitigation strategies: * don't use MBX with it's dependency upon /tmp * mount /tmp with symlinks disabled
Fix is in exim 4.72 http://vcs.exim.org/viewvc/exim/exim-src/src/transports/appendfile.c?r1=1.25&r2=1.26