------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=989
Summary: CVE-2010-2024 - MBX locking race condition
Product: Exim
Version: 4.71
Platform: All
OS/Version: All
Status: NEW
Severity: security
Priority: high
Component: Delivery in general
AssignedTo: nigel@???
ReportedBy: nigel@???
CC: exim-dev@???
Created an attachment (id=387)
--> (
http://bugs.exim.org/attachment.cgi?id=387)
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.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
