Vulnerability Development mailing list archives
why chmod race conditions are bad
From: Imran Ghory <imranghory () gmail com>
Date: Thu, 21 Apr 2005 23:52:17 +0100
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
Current thread:
- why chmod race conditions are bad Imran Ghory (Apr 22)