Date: Wed, 6 Aug 2003 19:22:49 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: bks10@cornell.edu Cc: freebsd-security@freebsd.org Subject: Re: statically compiled files left over after a 'make world' Message-ID: <20030806182249.GB29265@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <Pine.SOL.3.91.1030806130146.12164B-100000@travelers.mail.cornell.edu> References: <20030806092431.O18916-100000@kosh.etchings.com> <Pine.SOL.3.91.1030806130146.12164B-100000@travelers.mail.cornell.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--H1spWtNR+x+ondvy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 06, 2003 at 01:02:43PM -0400, bks10@cornell.edu wrote:
> If you track 4-STABLE you have nothing to worry about anyway. The bug did=
=20
> not affect 4-STABLE, only 4.8, 4.7, etc...
Incorrect. It says very plainly in the advisory:
FreeBSD 4-STABLE prior to May 22 17:11:44 2003 UTC
and it also affected all releases made prior to that date. That is,
all releases except 5.1-RELEASE which came out after the correction
was made to the sources.
=20
> Peace.
>=20
> On Wed, 6 Aug 2003, Brian Kraemer wrote:
>=20
> > Hello,
> >=20
> > I recently did a 'make world' to update my base system due to the realp=
ath
> > bug. After that finished, I noticed that I still had the following
> > statically compiled binaries laying around that did not get updated dur=
ing
> > a 'make world'. I track 4-STABLE.
> >=20
> > /usr/bin/miniperl
> > /sbin/mount_kernfs
> > /sbin/mount_devfs
> > /sbin/modunload
> > /sbin/modload
> > /sbin/ft
miniperl is (clearly) part of perl 5.005.03 -- as far as I can
remember, it's only needed during the compilation of perl in order to
bootstrap the compilation of the various loadable modules.
mount_kernfs and mount_devfs have been removed from stable --
mount_kernfs went fairly recently as I remember.
Similarly modunload, modload and ft are no longer present on a recent
4-STABLE system.
So, yes, all of those can be removed safely.
> > /stand/boot_crunch
> > /stand/find
> > /stand/sed
> > /stand/test
> > /stand/pwd
> > /stand/ppp
> > /stand/newfs
> > /stand/minigzip
> > /stand/cpio
> > /stand/bad144
> > /stand/fsck
> > /stand/ifconfig
> > /stand/route
> > /stand/slattach
> > /stand/mount_nfs
> > /stand/dhclient
> > /stand/arp
> > /stand/gzip
> > /stand/gunzip
> > /stand/zcat
> > /stand/-sh
> > /stand/[
> > /stand/sh
As other posters have said, you need to update /stand separately from
the rest of the system. Note that all of those files should be hard
linked together -- if you run
ls -lai /stand
you should see that they all share the same inode number. You may
need to fix up that linkage manually after rebuilding
/stand/sysinstall
> > Since they were not updated during a 'make world', does that mean that
> > they are deprecated and can be safely removed?
> > If not, why weren't they updated during a 'make world'? Is it a security
> > risk having them stick around since they haven't been re-linked against=
the
> > new libc?
In general, the most effective way finding files that have become
surplus to requirements over time is, as you have noted, to do a fresh
'make installworld' and hunt for files with timestamps older than the
rest. Even so, you need to apply a little discretion rather than
automatically deleting any older files. Or make sure you have good
backups readily available...
One important point: before starting on such an exercise, you need to
make sure that you haven't set:
INSTALL=3Dinstall -C
in /etc/make.conf -- that would cause install(1) to avoid overwriting
any files which was identical to what would be installed. In that
case, any statically linked binary that used the realpath(3) function
would necessarily be different to a version compiled before the fix,
and so certainly would have been replaced. Conversely, a dynamically
linked binary might not have been updated, even if it did use
realpath(3), as the applicable realpath(3) code would only affect the
shared library.
As to the files being a security risk -- potentially yes, but this bug
does take some effort to exploit: not all programs that use
realpath(3) may be exploitable, and in general, unless the programs
are SUID or SGID or accessible remotely (ie. by users without a login
on the system) the impact of exploiting the buffer overrun is not
going to allow the attacker to achieve significant privilege
escalation. In this case, subverting one of the programs under /stand
would gain the attacker nothing more than he could gain by simply
running /stand/sh directly.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--H1spWtNR+x+ondvy
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/MUd5dtESqEQa7a0RAmYmAJ4j6i2wopWx0GDP+7qSKcXzRGgyXwCdEstl
W1xPuEW7ZEkrGEfm+Cqn5j4=
=89XQ
-----END PGP SIGNATURE-----
--H1spWtNR+x+ondvy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030806182249.GB29265>