Re: [compress] Security considerations (bomb, links, absolute paths)
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: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > -- 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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] Security considerations (bomb, links, absolute paths)
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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] Security considerations (bomb, links, absolute paths)
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
