automake
[Top][All Lists]
Advanced

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

Re: Security vulnerability in automake


From: David Lee
Subject: Re: Security vulnerability in automake
Date: Mon, 10 Jun 2002 12:21:26 +0100 (BST)

On Sat, 8 Jun 2002, Bernd Jendrissek wrote:

> On Fri, Jun 07, 2002 at 04:50:23PM -0400, Lawrence Teo wrote:
> > 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.
> 
> [snip]
> 
> > 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.
> 
> An attacker is hardly likely to distribute a "hardened" config.guess
> 
> Build untrusted packages as root.  Hose your system.  Repeat until lesson
> is learned: do not built untrusted packages as root.

There seems to be a flaw there:  assuming that the attacker is the
distributor/provider of the package containing "config.guess".
          
But the attacker may well be a third party, exploiting a weakness in the
victim/builder's system as a weak, but innocent, package is installed.

If there is a weakness in "config.guess" (or anywhere else) that can be
reasonably fixed, shouldn't it be fixed?

All those of us with experience would agree that, ideally, package
building ought to be non-root. But I can think of at least one bona fide,
trustworthy package, Samba, that, on some platforms, can benefit from
being built as root as autoconf tries to discover something at root level
(from foggy memory, I seem to recall it was a runtime locking mechanism). 
 

Summary:

1. Attacker and package-provider may well be different parties;

1. If there is a weakness, root or otherwise, reasonable attempts should
be made to fix it, regardless of other considerations;
 
2. A non-root mindset should be encouraged.  Indeed, I'd support a case
for a default of "if root then abandon build", but with an override
capability for those (probably few) packages where root may be desirable
or even essential.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :




reply via email to

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