[svlug] A followup on UnZipping in Linux.

Mark S Bilk mark at cosmicpenguin.com
Wed Jan 23 15:07:01 PST 2002


In-Reply-To: <1011769239.1049.387.camel at theo.theotiwii.org>; 
from theotiwii at earthlink.net on Tue, Jan 22, 2002 at 11:00:38PM -0800

On Tue, Jan 22, 2002 at 11:00:38PM -0800, Ron wrote:
>Mark,
>
>That was complete, thank you for your research and your opinions.

You're very welcome.  I learned something important, which, 
incidentally, applies to the "tar" (un)archiver as well.

>There is only one significant issue that I would challenge, your
>statement:
>
>> No one is to blame.  <snip>
>
>I wasn't attempting to "blame" anyone (reference my email), I was
>looking for who was "responsible," as in, who do I address to prevent
>others from this "monumental time sink."
>
>Specifically, it seems UnZip should have either done the job OR posted a
>coherent message for refusing. Your input concerning a possible (most
>likely) patched version of UnZip indicates UnZip WOULD have done the job
>but the patch's author prevented the operation (yes, I understand the
>security implications) WITHOUT BOTHERING to include an advisory that
>would assist in understanding the behavior.
>
>If I did that to one of my customers... specifically, prevented _normal_
>code operation (for what ever reason) without the courtesy of generating
>a coherent explanation for the new behavior... 
>
>That's what I'm getting at, in that situation, everyone could be
>considered doing the "right" thing but "no product is generated (files
>unzipped)." Who is responsible? In _my opinion_ it is the author of the
>patch.

I did say that the program's refusal to extract archive
members to an absolute path "should be documented in the man 
page and/or the help printout".

And I would add that an explanation of the reason for 
refusing -- namely the inherent danger of archive extraction 
to destinations outside the current directory -- should be 
documented as well.

However, as I now think about it, an archive containing 
members with absolute paths may be very unusual.  I don't 
recall ever having seen one before.  I just went back to my 
old MS-DOS hard disk, and in the half-dozen zipfiles I found 
(some that I had made, and some that I had downloaded) in 
which the members have paths, they are all relative.  Which
makes sense for convenience, as well as security, even under
DOS.  Unless the destination for the archived material is 
in exactly the same place as it was in the directory 
structure of the source filesystem, extraction to absolute 
paths would make a (possibly dangerous) mess.

So the authors of Info-(un)zip and its security patch may
be excused for not documenting program behavior which they
thought would only occur extremely rarely, and possibly only
in response to an archive that was intentionally designed
to cause damage (which of course was not the case here).

>I'm not trashing anyone or any product or starting a smear campaign
>against community supported software AND NONE of my emails has said OR
>implied that. When I presented, as a potential reason:
>
>>     D. Unzip in Linux is user malicious,
>>        good luck if the user isn't perfect...
>
>I do not consider it an abuse of community supported software, and quite
>frankly, I'm currently hard pressed not to consider it as the correct
>answer.

I _strongly_ disagree!  I cannot understand why you would 
now say that, and I think it _is_ a smear against Info-zip 
and its creators.

>But... I digress, Mark has provided excellent insight into the dynamics
>of my problem and has included thoughtful opinions of the issues I
>faced. Thank you for your help and for sharing some of your experience
>and commitment to the Unix community.

Well, I've just shared some more of it.  Unless you can point 
to some other absolute-path zip archives, and valid reasons
for their being that way, I think you should back off of your 
"malicious" claim.

>PS: Pete (Carapetyan - WebAppWriter), there are versions of UnZip on
>Linux and other flavors of Unix that have been patched to prevent
>"directory-traversal" (reference this URL:)
>
>	http://www.info-zip.org/FAQ.html#corruption

Actually, I Cc'ed him on my previous (but not my first) post,
as well as this one, without knowing who he was, because you 
(Ron) had done so. 8^)  Hi Pete!

>Some of the above users may be puzzled by the operation of UnZip on the
>files you are generating for that reason. Although the use of the
>command line option "-d" will allow the user to unzip the files, 

Specifically (since Pete didn't see my first post), the 
use of the option "-d altdir" in unzip's command line will 
extract the files as a subtree under directory altdir (which
can be an absolute path that ends outside the current 
directory -- I just tried it).

>perhaps
>you might consider removing your use of relative paths as, in the

I'm sure Ron meant to say, "removing your use of _absolute_ 
paths" (and replacing them with relative ones).

>opinion of this user, the resulting error message is not definitive to
>allow inexperienced unzip users to successfully accomplish the task. :-)

In the opinion of _this_ user, _nobody_ should be able to 
successfully unzip archived files into directories that are
not under the current directory (at least not without having 
to manually give the -d option, which explicitly specifies 
the destination directory).  In the present case, for example,
being able to do so would obliterate without warning any file 
named "foo" in the root directory.  Even in MS-Windows you 
wouldn't want to do that without knowing about it beforehand!

OK, that horse is dead!  Bye!

  Mark





More information about the svlug mailing list