I just noticed the Bugzilla entries for these issues. I wanted to
point out that the impact of the second bug is more than just creating
empty files - because of the chmod() call, permissions on the victim's
files may be changed.
That being said, I have yet to come across a system that uses MBX
locking, with a dependency on /tmp, AND allows symlink following on
/tmp. So I think it would be perfectly appropriate not to address the
race condition in the code in favor of making it explicitly clear in
the documentation that this particular combination of configurations
is potentially unsafe.
I'd like to publish an advisory for these issues, just in case any
users are affected and don't follow Exim upstream carefully. I'll be
sure to emphasize the somewhat low impact, which configurations are
vulnerable, and mitigation strategies.
Is there an idea of when 4.72 will be ready? Are there plans on
addressing the MBX issue further?
Thanks,
Dan
On Tue, May 25, 2010 at 11:32 AM, Phil Pennock <pdp@???> wrote:
> On 2010-05-25 at 11:21 -0400, Dan Rosenberg wrote:
>> Thanks for the prompt response.
>>
>> For the first issue, it's not a matter of reading a user's mail, but
>> causing mail deliveries to that user to overwrite other files owned by
>> that user. For example, if we use your example of victim "foo" and
>> attacker "bar", where "foo" has no mailbox, "bar" can create a
>> hardlink to another one of foo's files, such as /home/foo/.bashrc.
>> Subsequent mail delivery will append to this file, allowing an
>> attacker to append information to other users' files.
>
> Oh, of course. Too used to separate file-systems for /home and
> /var ...
>
>> 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.
>
> Okay, so the problem is again symlink following, this time leading to
> empty file creation. And the many systems which unfortunately still
> follow symlinks in /tmp :(
>
> Mounting /tmp with nosymfollow or whatever the GNU/Linux equivalent is
> will mitigate against this attack.
>
>> 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.
>
> Nope, clearer now.
>
> Graeme, Nigel: I'm not sure that I'll have any time for this today. :(
>
> -Phil
>
