Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jai
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 16, 2007 at 02:42:17PM +1100, Bruce Evans wrote:
> On Tue, 16 Jan 2007, Dirk Engling wrote:
>=20
> >Colin Percival wrote:
> >
> >>No. `cp -f` unlinks the existing file and creates a new file, but will
> >>still follow a symlink if one is created between the "unlink" syscall a=
nd
> >>the "open" syscall.
> >...
> >You are right. Atomically in binary is not atomical enough.
> >
> >mv in its rename()-form will do the job, so we need to create a file in
> >. by mktemp and mv it to the real name when filled.
>=20
> install -S already implements this, but not robustly enough to be secure.
> It only creates the temporary file if the target doesn't already exists,
> so it is subject to the usual races otherwise. 'S' stands for "safe"
> (no-clobber), not secure, so this is reasonable. However, it can easily
> be made both safer (actually no-clobber) and securer by opening the file
> with O_EXCL and exiting if the file exists at the time of the open.
> Perhaps cp -f should do the same. (Both have paths where they do a
> forced unlink() followed by an open(). This open() can easily use O_EXCL=
).
Interesting. I was sure it won't work as you described, because the
target file can be a symlink and open(2) by default follows symlinks.
I thought that you just forget about O_NOFOLLOW flag, but it seems, that
with O_EXCL open(2) doesn't follow symlinks so it will work.
> mv(1) can never be trusted to use its rename() form since it uses
> copying to move across file systems and there is no way to control this.
> mv(1)'s rewriting of "mv file dir" to "rename file dir/file" is also
> a problem (I keep rename(1) handy to avoid it). I haven't followed
> most of this thread so I don't know what the attacker can do here.
> Changing the target to a symlink to a directory on a different file
> system would exploit both of the problems in mv.
That's true. Dirk's proposal is to create a file with mktemp(1) in the
same directory where we're going to rename(2) the file, but I don't
think mktemp(1) will be safe here:
good-guy attacker-within-a-jail
cd /jail/var/log
mktemp foo.XXX
rm -f foo.XXX
ln -s /etc/spwd.db foo.XXX
copy /path/to/jail_console.log foo.XXX
mv -f foo.XXX console.log
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFrJADForvXbEpPzQRAoJJAJ4phBMyAMl1ZhWnj/3r3cNeWDnChQCgoWGx
TxRmmvgdjgWsVF+VOosFaXU=
=vPbG
-----END PGP SIGNATURE-----
--mP3DRpeJDSE+ciuQ--
討論串 (同標題文章)
完整討論串 (本文為第 14 之 22 篇)：