Re: Security vulnerability in automake

[Lawrence Teo]

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.

Lawrence


> 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?
>
> Allan
>
>
> 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:
> >
> > dummy=dummy-$$
> >
> > 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: 
http://photos.msn.com/support/worldwide.aspx