Date: Tue, 1 Oct 2002 17:12:27 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jan@caustic.org Cc: brett@lariat.org, kris@obsecurity.org, dillon@apollo.backplane.com, piechota@argolis.org, aaron@namba1.com, security@FreeBSD.ORG Subject: Re: RE: Is FreeBSD's tar susceptible to this? Message-ID: <200210020012.g920CRvU014531@gw.catspoiler.org> In-Reply-To: <20021001163239.L67581-100000@pogo.caustic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Oct, f.johan.beisser wrote: > On Tue, 1 Oct 2002, Don Lewis wrote: > >> On 1 Oct, f.johan.beisser wrote: >> > i don't believe that tar(1) will allow you to do that by default. >> >> I don't have an easy way of creating a malicious tarball to do this all >> in one shot, but it does look like our tar follows symlinks. I forgot about tar's "r" option ... > it doesn't include them by default, though. well, the symlink, yes; the > contents of the symlink, no. > > in your example, overwriting a given simlink works because it's > pre-existing, before the untarring of the file. essentially, it's like > cd'ing in to a symlinked directory: The symlink doesn't have to exist ahead of time. % rm -rf foo baz % ls foo baz ls: baz: No such file or directory ls: foo: No such file or directory % ln -s baz foo % tar cvf foo.tar foo foo % rm foo % mkdir foo baz % touch foo/bar % tar rvf foo.tar foo/bar foo/bar % rm -r foo % tar xvf foo.tar foo foo/bar % ls -al foo baz lrwxr-xr-x 1 dl dl 3 Oct 1 17:01 foo -> baz baz: total 28 drwxr-xr-x 2 dl dl 512 Oct 1 17:01 . drwxr-xr-x 64 dl dl 27648 Oct 1 17:01 .. -rw-r--r-- 1 dl dl 0 Oct 1 17:00 bar >> The only safe way of preventing symlinks from being followed would be to >> lstat() each component of each path name in the tarball (which is still >> not safe if there is a hostile process running that could substitute a >> symlink for something that has already been checked). > > if you have a hostile process, you tend to be forced in to assuming the > machine is hostile anyway, yes? Yes, I just didn't want anyone to get the impression that the checks that I mentioned above are safe in all cases. In the general case, even those checks are vulnerable to things like /tmp races. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210020012.g920CRvU014531>