commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Security considerations (bomb, links, absolute paths)
Date Fri, 19 May 2017 11:16:55 GMT
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.


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

View raw message