|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: f.johan.beisser (jan_at_caustic.org)
Date: Tue Oct 01 2002 - 18:48:39 CDT
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.
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:
[jan
hi jan] {102}$ ln -s /tmp tmphome
[jan
hi jan] {103}$ ls -al tmphome
lrwxr-xr-x 1 jan jan 4 Oct 1 16:38 tmphome -> /tmp
[jan
hi jan] {104}$ cd tmphome
[jan
hi tmphome] {105}$ pwd
/home/jan/tmphome
[jan
hi tmphome] {106}$ ls -l
drwxr-xr-x 2 jan wheel 512 Aug 1 13:21 ook
drwx------ 2 jan wheel 512 Sep 27 13:36 orbit-jan
drwxr-xr-x 3 root wheel 512 May 23 16:57 screens
if i untar something to $HOME/tmphome, it'll end up in /tmp.
> Our -L option does something entirely different, which is odd since I
> got the impression from the comments made in this thread that both
> FreeBSD and OpenBSD are both using gtar.
no, it appears that FreeBSD is using gtar by default, which means the
pax(1) link i posted earlier is wrong. From the FreeBSD tar(1) man page:
COMPATIBILITY
The -y is a FreeBSD localism. The GNU tar maintainer has now choosen
-j as the offical bzip2(1) compression option in GNU tar 1.13.18 and
later. The -I option is for compatibility with Solaris's tar.
[...]
HISTORY
The tar format has a rich history, dating back to Sixth Edition UNIX.
The current implementation of tar is the GNU implementation, which
originated as the public-domain tar written by John Gilmore.
> I also don't think the -L option described above (or the lack of it's
> use) does anything to help the problem. If there is a symbolic link
> named "foo" in the filesystem and the tarball contains a directory named
> "foo", then it sounds like the symlink will be removed and replaced with
> a directory if the "-L" option is not used, and the directory will be
> created at the target of the symlink if the "-L" option is used. It
> doesn't seem to say anything about what is done if there is no "foo"
> directory in the tarball, but the tarball contains a "foo/bar" file.
the -L flag in OpenBSD's tar will permit tar to follow symlinks, vs
overwriting them or, worse, allowing something to overwrite outside of the
untarring location. this assumes i'm reading the man page correctly.
> 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?
-------/ f. johan beisser /--------------------------------------+
http://caustic.org/~jan jan
caustic.org
"John Ashcroft is really just the reanimated corpse
of J. Edgar Hoover." -- Tim Triche
To Unsubscribe: send mail to majordomo
FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]