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 Thu, 18 May 2017 16:17:42 GMT
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.



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

View raw message