Onderwerp: Symlink Vulnerability in GNU libtool <1.5.2

Vulnerable: libtool <1.5.2
Not Vulnerable: libtool 1.5.2
Project website: http://www.gnu.org/software/libtool/libtool.html

Description of libtool (from website):
"GNU libtool is a generic library support script. Libtool hides the
complexity of using shared libraries behind a consistent, portable
interface."
Libtool is included with many packages that rely on it to handle
libraries. As a result these packages are vulnerable as well.


Discussion:
I found a symlink vulnerability in libtool prior to version 1.5.2.
Libtool insecurely creates a temporary directory when a package using
libtool is being compiled.

I want to point out that this bug is _only_ exploitable at compile time.
The binaries that are produced during compilation are _not_ affected. As
a result, systems that rely exclusively on binary packages are not
affected at all.


Solution:
Updating to libtool 1.5.2 (the current stable release) will eliminate
the vulnerability. If you want to stick with your old version of libtool
you can easily fix this bug yourself. In "ltmain.in" (or file "libtool",
whichever applies for you) you should replace the line:

if $mkdir -p "$tmpdir" && chmod 700 "$tmpdir"; then :

with

if $mkdir "$tmpdir" && chmod 700 "$tmpdir"; then :

Packages sometimes bring their own version of libtool. As a result,
fixing the libtool that is installed on your system may not be enough.
To solve this problem, package maintainers should fix their packages if
they use libtool!


Regards
Stefan Nordhausen

--
Don't open your eyes, you won't like what you see. The blind have been
blessed with security. Don't open your eyes, take it from me. I have
found, you can find happiness in slavery.
Trent Reznor

I wrote:
> If you want to stick with your old version of libtool
> you can easily fix this bug yourself. In "ltmain.in"
> [...] you should replace the line:

This fix will not work for the version of libtool that is distributed
with SuSE Linux (checked on SuSE 8.2/9.0). SuSE modified the tempdir
creation to use mktemp if available. As a result the patch mentioned
above would break SuSE's libtool, so don't use it for your SuSE Linux!

Unfortunately, the changes made by SuSE don't fix the vulnerability
(they just make it a bit harder to exploit) so that it is still
necessary to apply a bugfix.

Regards
Stefan

--
Don't open your eyes, you won't like what you see. The devils of truth
steal the souls of the free. Don't open your eyes, take it from me. I
have found, you can find happiness in slavery.
Trent Reznor

On Fri, 30 Jan 2004, Stefan Nordhausen wrote:

> Solution:
> Updating to libtool 1.5.2 (the current stable release) will eliminate
> the vulnerability. If you want to stick with your old version of libtool
> you can easily fix this bug yourself. In "ltmain.in" (or file "libtool",
> whichever applies for you) you should replace the line:
>
> if $mkdir -p "$tmpdir" && chmod 700 "$tmpdir"; then :
>
> with
>
> if $mkdir "$tmpdir" && chmod 700 "$tmpdir"; then :

The chmod has a race (that access to the temporary directory could be
gained after it is created but before it is chmoded) - which I pointed out
when I reported this security bug four years ago
<http://www.geocrawler.com/mail/msg.p...38808&list=405> - so is
of limited security value. Alexandre Oliva's patch at that time
(<orsnxk8oqu.fsf@garnize.lsd.ic.unicamp.br> on libtool-patches) used umask
to avoid that problem, but wasn't committed (an entirely separate patch
was committed under that log message).

--
Joseph S. Myers
jsm@polyomino.org.uk

Joseph S. Myers wrote:
> The chmod has a race (that access to the temporary directory could be
> gained after it is created but before it is chmoded) - which I pointed out
> when I reported this security bug four years ago
> <http://www.geocrawler.com/mail/msg.p...38808&list=405>

Hm, interesting. That is the exact same bug that I found. As for the
race with chmod: Do you know of a really good way to exploit this one? I
can only think of pretty harmless things to do with this. You could fix
this by using something like:

(umask 077 && mkdir $tmpdir) || exit 1

But once you are at it you should also change the way the name of the
directory is generated. By predicting it an attacker can keep libtool
from creating its temporary directories. That means libtool will not
completely do its job. In contrast to the little chmod race this could
actually be a problem. A fix could be something like:

tmpdir="$tmpdir.$RANDOM.$RANDOM.$RANDOM"

But then again this could all just be paranoia. The chmod race is AFAIK
hardly a risk and the second issue applies to pretty much every shell
script that doesn't use mktemp.

But that's no reason not to fix it. Based on some code from libtool you
would get:


tmpdir="/tmp"
test -n "$TMPDIR" && tmpdir="$TMPDIR"
tmpdir="$tmpdir/libtool-$$.RANDOM.$RANDOM.$RANDOM"
(umask 077 && $mkdir "$tmpdir") || {
$echo "some error message" 1>&2
continue
}


Regards
Stefan Nordhausen

--=-UwDLgg4hDwheSMmRXyhP
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-02-03 at 09:47, Joseph S. Myers wrote:

> On Fri, 30 Jan 2004, Stefan Nordhausen wrote:
> > Solution:
> > Updating to libtool 1.5.2 (the current stable release) will eliminate
> > the vulnerability. If you want to stick with your old version of libtoo=
l
> > you can easily fix this bug yourself. In "ltmain.in" (or file "libtool"=
,=20
> > whichever applies for you) you should replace the line:
> >=20
> The chmod has a race (that access to the temporary directory could be
> gained after it is created but before it is chmoded)
>=20
Would this patch be sufficient? Gary et al. okay to apply if it is?

----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8=
<----
2003-02-03 Scott James Remnant <scott@netsplit.com>

* ltmain.in: Create temporary directory under a strict umask
rather than running chmod afterwards, preventing a race
condition where the directory could be replaced with a symbolic
link in the time between the two commands.

diff -u -r1.334.2.20 ltmain.in
--- ltmain.in 3 Feb 2004 19:55:29 -0000 1.334.2.20
+++ ltmain.in 3 Feb 2004 20:29:07 -0000
@@ -5673,11 +5673,15 @@
tmpdir=3D"/tmp"
test -n "$TMPDIR" && tmpdir=3D"$TMPDIR"
tmpdir=3D"$tmpdir/libtool-$$"
- if $mkdir "$tmpdir" && chmod 700 "$tmpdir"; then :
+ save_umask=3D`umask`
+ umask 0077
+ if $mkdir "$tmpdir"; then
+ umask $save_umask
else
+ umask $save_umask
$echo "$modename: error: cannot create temporary directory =
\`$tmpdir'" 1>&2
continue
fi
file=3D`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'`
outputname=3D"$tmpdir/$file"
# Replace the output file specification.
---->8-------->8-------->8-------->8-------->8-------->8-------->8-------->=
8----

Scott
--=20
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?


--=-UwDLgg4hDwheSMmRXyhP
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBAIAW2IexP3IStZ2wRAin9AJ9Mj85MPktW6teW6Pz0P2 Z6Kh9dMgCfQf8b
zeItGZpFMKD25WRSoTbuFRA=
=LFg6
-----END PGP SIGNATURE-----

--=-UwDLgg4hDwheSMmRXyhP--

ÿþpvheader: wHlck8DhilDjPLXvroKfLXJlqWUwq5UyOUnushJMl2qybE0idT VTOxwv0SiKj/0Vzql9YluLQrH+auHyTPYA9NscnODJl1AR4mHFSW54++mWa390 jQ4ShePCufy+SNqqFHKyB0f1GHrsaIHxYKumYMO/M3RcmoEz
Content-Class: urn:content-classes:message
From: "Joseph S. Myers" <jsm@polyomino.org.uk>
Date: Tue, 3 Feb 2004 21:01:50 -0800
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Delivered-To: mailing list bugtraq@securityfocus.com
Delivered-To: moderator for bugtraq@securityfocus.com
Sender: "Joseph S. Myers" <jsm@polyomino.org.uk>
Return-Path: <bugtraq-return-12765-mleebert=diversa.com@securityfocus.com>

On Fri, 30 Jan 2004, Stefan Nordhausen wrote:

> Solution:
> Updating to libtool 1.5.2 (the current stable release) will eliminate
> the vulnerability. If you want to stick with your old version of libtool
> you can easily fix this bug yourself. In "ltmain.in" (or file "libtool",
> whichever applies for you) you should replace the line:
>
> if $mkdir -p "$tmpdir" && chmod 700 "$tmpdir"; then :
>
> with
>
> if $mkdir "$tmpdir" && chmod 700 "$tmpdir"; then :

The chmod has a race (that access to the temporary directory could be
gained after it is created but before it is chmoded) - which I pointed out
when I reported this security bug four years ago
<http://www.geocrawler.com/mail/msg.p...38808&list=405> - so is
of limited security value. Alexandre Oliva's patch at that time
(<orsnxk8oqu.fsf@garnize.lsd.ic.unicamp.br> on libtool-patches) used umask
to avoid that problem, but wasn't committed (an entirely separate patch
was committed under that log message).

--
Joseph S. Myers
jsm@polyomino.org.uk