Subject: Re: tar ignores filenames that contain `..'
To: Frederick Bruckman <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/28/2002 01:55:24
[ On Sunday, October 27, 2002 at 22:27:20 (-0600), Frederick Bruckman wrote: ]
> Subject: Re: tar ignores filenames that contain `..'
> Uh... how does your race condition leverage privilege? It seems an
> attacker would need to already have an account with the same privilege
> as the targetted user to accomplish anything. But then..., all he
> could accomplish, is the ability to write files with the privilege of
> the targetted user, which he could already trivially do.
The attacker need only convince the admin to unpack the "tainted"
archive and then lay in wait for the unpacking to begin. Unless I'm
mistaken if the unpacking is done in such a way that permissions (and/or
ownerships, if the target user is root) from archive are preserved then
it can be arranged such that a directory in created hierarchy will be
writable by the attacker while the un-archiving is still happening to
files in some subdirectory of it (eg. it's mode 777 and though the admin
looked at a listing first and spotted this problem he feels he can just
fix it after unpacking the archive). One quick rename and a symlink in
the right place at the right time and the attacker gets to overwrite
practically any file with anything the user doing the unpacking can
write to (and with care in creation of the archive this doesn't even
have to be very carefully timed at attack time). As far as I know
without the open()/fstat()/fchdir() dance, or some new flag to open(2)
to prevent following symlinks during path traversal, you can't know for
sure that some directory in a pathname prefix hasn't been replaced by a
symlink in the time since you last looked at it.
Yes, I believe Todd's proposal should adequately address the threat of a
self-contained trojan in the archive and thus addresses the primary
concern of the advisory. However that's only part of the problem of
dealing safely with archive data that an attacker might be in full
control of, which is what I felt the intent of the additional commentary
of the advisory that I quoted was all about.
We all fully expect admins to run de-archivers as the superuser very
frequently to examine and extract files from archives which must be
treated as potentially hostile in their construction and content.
Therefore "we" must take great care to write the tools which do this
archive examination and extraction just as carefully as we must write
any other privileged code, and especially those which deal with and act
upon foreign data.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>