Quantcast

[compress] Security considerations (bomb, links, absolute paths)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[compress] Security considerations (bomb, links, absolute paths)

Benedikt Tröster
Hello everyone!

I'm currently reviewing some code where the commons compress library has
been used. As far as I can tell there haven't been many security
vulnerabilities with this lib. I wonder however, how one would ensure
protection against ZIP-Bombs, extraction of links and absolute paths
(e.g. 7zip)?
I can't find any documentation on this.

You Input is very much appreciated! :)

Best,
Benedikt

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [compress] Security considerations (bomb, links, absolute paths)

Stefan Bodewig
Hi Benedikt

I'm sure my response is incomplete.

On 2017-05-18, Benedikt Tröster wrote:

> As far as I can tell there haven't been many security vulnerabilities
> with this lib.

Likely because it only provides an API that's pretty much low-level, the
dangerous parts are about to happen inside the code that uses Compress.

The one vulnerabilty we had really only came down to bad worst case
performance in bzip2. So if I made you compress a specially crafted
stream, it could take ages and eat up a core completely. It is certainly
possible that some of our stream implementations are sub-optimal for
certain inputs still.

> I wonder however, how one would ensure protection against ZIP-Bombs,
> extraction of links and absolute paths (e.g. 7zip)?  I can't find any
> documentation on this.

Compress doesn't extract anything to disk by itself. It is the user code
that decides what to do with the paths and how to deal with
links. 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.

For the problem of ZIP bombs Compress doesn't offer too much. For
many formats you can know the size of an entry before you start
extracting it, so you could use that to stop processing if an entry
would become too big. This is not true all formats, though, like a ZIP
archive read from a non-seekable stream if it has been created in a
certain way.

With 1.14 we've started to add some control knobs to some of the
compression formats. You can now specify a maximum amount of memory that
processing of Z, LZMA and XZ compressed streams is allowed to
use. Technically some of the other formats could provide similar
controls. But all it does is controlling the transient memory used
during decompression, it doesn't have any effect on the size of the
decompressed output. It is still up to the application using Compress to
determine whether an output is getting too big and stop processing.

HTH

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [compress] Security considerations (bomb, links, absolute paths)

Benedikt Tröster
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"?

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?

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?

Is it possible to determine if an Entry is actually a Symlink?

Thanks so much for your help!

Best,
Benedikt

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [compress] Security considerations (bomb, links, absolute paths)

Bruno P. Kinoshita-3
In reply to this post by Benedikt Tröster
Some time ago while working with mapserver, I did a quick wrap in C++ to use afl fuzzifier and found some interesting things, but no critical issues. I wonder if it would be possible to fuzzify a Java library too like compress, or even if that would make sense.

I've added it to my rainy-day-TODO-list anyway :-) in the same way we have JMH tests for performance, maybe we could have a profile that activates fuzzification... I guess?

Cheers
Bruno



________________________________
From: Benedikt Tröster <[hidden email]>
To: [hidden email]
Sent: Friday, 19 May 2017 3:18 AM
Subject: [compress] Security considerations (bomb, links, absolute paths)



Hello everyone!


I'm currently reviewing some code where the commons compress library has

been used. As far as I can tell there haven't been many security

vulnerabilities with this lib. I wonder however, how one would ensure

protection against ZIP-Bombs, extraction of links and absolute paths

(e.g. 7zip)?

I can't find any documentation on this.


You Input is very much appreciated! :)


Best,

Benedikt


---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [compress] Security considerations (bomb, links, absolute paths)

Stefan Bodewig
In reply to this post by Benedikt Tröster
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [compress] Security considerations (bomb, links, absolute paths)

Benedikt Tröster
Hello again!

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

Wish you well.

Best,
Benedikt

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Benedikt Tröster

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

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...