why chmod race conditions are bad

[Imran Ghory <imranghory () gmail com>]

This message was rejected by bugtraq but as I think it contains some
useful explainations I decided to post it here instead.

---------- Forwarded message ----------
---------- Forwarded message ----------
From: Imran Ghory <imranghory () gmail com>
To: bugtraq () securityfocus com
Date: Sat, 16 Apr 2005 23:21:40 +0100
Subject: Re: ================================ GNU Core Utilities race
condition file-permissions vulnerability
================================ Software: mkdir, mknod, mkfifo
Version: Part of GNU Core Utilities 5.
On 4/16/05, Pavel Kankovsky <peak () argo troja mff cuni cz> wrote:
> ...and the next step will be an advisory about a race condition in
> chmod itself? Or, to be more precise, in the use of chmod, i.e. between
> the moment the user looks at the file and decides to change its attributes
> and the moment the change is done.
>
> And what about a nasty vulnerability in the shell making it possible to
> overwrite an arbitrary file of yours when you use ">" on a file in a
> directory writeable by other users? Not to mention hundreds of other
> programs being able to rewrite or modify existing files.

Yes but with those issues it is well known and understood by most
sysadmins and many users.

Also you have to remember for these bugs to be exploited just require
an attacker to have write access to the directory being used, the most
common situation is a directory being group/other write privileged,
however it also applies to directories which the attacker owns. This
later situation obviously will only apply when the victim has root
privilege so is much more uncommon, however the rewards for the
attacker are much higher. What you are essentially suggesting is that
root users should not use any commands in a users directory, which for
many sysadmins is unacceptable.

When you operate in a directory in which you know someone else has
write access to you accept that they will be able to modify files in
that directory. You shouldn't however have to accept that they will be
able to steal your account.

If someone can cause a chmod gaining write permission to an arbitrary
file of yours it is trivial for them to gain control of your account
(for example by changing post-login startup scripts). Yes this problem
does exist with chmod, and it is arguable that it is intrinsic,
however this problem is not intrinsic in mkdir/gzip/bzip2/cpio/etc in
most cases these can be fixed by changing the code to use fchmod
instead of chmod.

All of these vulnerabilities are real and are exploitable, the more
commonly used a package the more dangerous these bugs are as they're
more likely to present an opportunity for attack and all of these
packages are very common.

In combination with other factors these attacks are practical on a
system which might be otherwise regarded as secure, several people
have already suggested using social engineering in combination with
these vulnerabilities to gain root access.

Programs which blindly write to a file without warning the user that
they are about to over-write an existing file or a file are a risk,
although a far lower one than chmod vulnerabilities. This is simply
because all these will do is overwrite a file with something that is
not under the attackers control so in most cases the worst they can do
is cause a denial-of-service style attack. This is far less serious
than an account compromise or loss of confidentiality & integrity of
files that can be caused by a chmod bug.

As for you argument that there might be hundreds of programs with such
vulnerabilities, I accept such a thing might be true (although I don't
personally believe that a vast number of programs actually use chmod),
but the argument surely is facetious as there are thousands of
programs that have buffer overflow vulnerabilities, yet no-one is
suggesting (I hope at least) that we ignore those vulnerabilities as
they are too common.

Essentially it all boils down to the fact that these program are
vulnerable to an attack that can result in account compromise, and
these programs can be rewritten (in many cases trivially) so that this
vulnerability no longer exists. This in my belief makes them worthy of
an advisory. After all to compromise an account an attacker has to be
lucky only once, to defend a system a sysadmin has to be lucky every
time.

--
Imran Ghory