[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security vulnerability in automake

From: Lawrence Teo
Subject: Re: Security vulnerability in automake
Date: Fri, 07 Jun 2002 16:50:23 -0400

Dear Allan,

I agree with you on many points but I still think this is an issue.

Yes, people like you and me don't build stuff as root, because we're aware of the security issues behind this. However, "normal" users like newbie admins probably don't.

Yes, standard users cannot overwrite /etc/passwd. But let's say we have a newbie admin who always builds and installs his stuff like this:

$ su -
# cd /tmp
# tar zxvf package-1.0.0.tar.gz
# cd package-1.0.0
# ./configure
# make
# make install

If an attacker observes this behavior, the attacker may do this:

$ cd /tmp
$ mkdir package-1.0.0
$ cd package-1.0.0
$ ln -s /etc/passwd dummy-7836.c

..and wait for the newbie admin to build his package. If config.guess happens to run as PID 7836, /etc/passwd is hosed.

Yes, the vulnerability would still be there even with a random hashed name. But it would be much, much harder for an attacker to exploit that, especially if we use a good hashing algorithm. It's almost impossible to guess dummy-7836-2c7f55d3aae7037c094b116d7b257b89.c compared to dummy-7836.c.

My point is, if config.guess can be hardened against such potential symlink attacks, why shouldn't it be? Of course, it would be great to educate all admins not to build stuff as root. But it would also be a responsible thing to fix config.guess if we know that there's a potential issue in there.

Here's an analogy: we used to have unshadowed /etc/passwd files a long time ago. To improve security, we introduced shadowed password files. This won't prevent an admin from using a weak password like "hello" in both scenarios. In the case of the unshadowed password file, it's easy for an attacker to run a dictionary attack against it and retrieve the weak password. However, it's much harder for an attacker to guess a password because of an inaccessible shadowed password file, even if the password is weak.

Likewise, having a "hardened" config.guess file would not necessarily prevent symlink attacks, but it'll definitely make it much harder for an attacker to exploit it, even if the admin is sloppy.


From: Allan Clark <address@hidden>
To: Lawrence Teo <address@hidden>
CC: address@hidden
Subject: Re: Security vulnerability in automake
Date: Sun, 09 Jun 2002 01:20:01 -0700

This is really not an issue; standard users cannot overwrite /etc/passwd

You don't compile/install unknown software as root, do you?  If so, then
my configure file says this:
date > /etc/passwd

Sure, this could be replaced with a hashed random name, but the same
vulnerability remains.  Don't build as root?


Lawrence Teo wrote:

I was learning Automake last night, and I think I found a security
vulnerability. I'm not sure if this is already known, but I couldn't
find it on Bugtraq. The security vulnerability is the insecure
creation of temporary files in the config.guess script which leads
to a race condition.

In the config.guess script, there's a line that says:


And further down...

echo "int dummy(){}" > $dummy.c ;

An attacker can create a number of symbolic links called
dummy-PID.c pointing to important files like /etc/passwd. PID in
this case would be the attacker's guesses on what the PID of the
config.guess script will run as. If root runs ./configure in a
source tree containing these malicious symlinks, and if the
configure script in turn runs config.guess, the /etc/passwd file
may potentially be overwritten with "int dummy(){}", resulting in
a denial of service attack.

MSN Photos is the easiest way to share and print your photos:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]