Re: Symlink Vulnerability in GNU libtool <1.5.2

[Bob Friesenhahn]

On Tue, 3 Feb 2004, Scott James Remnant wrote:

> On Tue, 2004-02-03 at 21:49, Gary V.Vaughan wrote:
>
> > On Tuesday, February 3, 2004, at 08:33  pm, Scott James Remnant wrote:
> > > On Tue, 2004-02-03 at 09:47, 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)
> > >>
> > > Would this patch be sufficient?  Gary et al. okay to apply if it is?
> > >
> > > 2003-02-03  Scott James Remnant  <address@hidden>
> > >
> > >   * 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.
> >
> > Looks good from here.
> >
> Committed to HEAD and branch-1-5.
>
> Now... the tricky question, do we think this should warrant a new
> release?

I would like to understand the issue better.  If the temporary
directory is lacking the 't' permissions attribute required to ensure
that users can not remove or rename files they didn't create, then the
new directory could be moved, and a symbolic link subsituted.  This
would result in an insecure /tmp directory overall, which effects a
lot more than libtool.

Is there any other situation where the race condition could be
exploited?  How many thousands (or millions) of systems are using
software with an insecure libtool?  Will securing 1.5.X help secure
those systems?

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen