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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org