commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Tröster <>
Subject Re: [compress] Security considerations (bomb, links, absolute paths)
Date Tue, 23 May 2017 09:12:16 GMT
Hello again!

I wanted to thank you guys for your input! It is greatly appreciated. :)

Wish you well.


Am 19.05.17 um 13:16 schrieb Stefan Bodewig:
> On 2017-05-18, Benedikt Tröster wrote:
>> Hi Stefan,
>> thanks a lot for your detailed answer! That explained most of my concerns.
>> However here are some things I have questions about:
>> Am 18.05.17 um 18:17 schrieb Stefan Bodewig:
>>> Compress will give you the path as it is contained inside the
>>> archive but if an aplication blindly accepts an absolute path, it is the
>>> applications fault.
>> How would one receive the path from the archive? Would getName() contain
>> a full path (if given in the archive) such as "/etc/passwd"? or will it
>> always contain the file name "passwd"?
> If the format stored the file name as /etc/passwd getName() would return
> /etc/passwd. This may be the case for tar for example, but other formats
> like ZIP don't allow leading slashes.
>> When protecting against ZIP bombs I guess you would do a size check
>> before unpacking via getSize(), right? You said this is not available
>> for every file type, is there documentation for which archive type it is
>> not available?
> Not in a single place. But rather scattered. From the top of my head you
> should have the size information for all archiving formats except for
> ZIP, and if your used ZipFile instead of ZipArchiveInputStream the
> uncompressed size will always be there as well. ZipArchiveInputStream
> may know the size before extracting the stream only under certain
> conditions depending on the compression format and how the archive has
> been created.
> Most of the compression formats don't know the uncompresed size.
>> If a ZIP file contains a ZIP file itself, this will not automatically be
>> "resolved" by the library, right? As a dev you'd have start a new
>> decompression process on the ArchiveEntry containing the second level
>> archive, right?
> This is correct.
>> Is it possible to determine if an Entry is actually a Symlink?
> Most formats don't support symlinks at all. Those who do have
> corresponding isXXX methods on the *ArchiveEntry subclasses.
> If your application doesn't look at those flags, it is going to treat
> the entries as plain files - and usually obtain the target name as the
> content. This won't turn the file into a symlink by itself.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Benedikt Tröster

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - - Mobile
+49 151 16227792 - Fax 6221 419008

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message