This PR aims to fix #407 (reserved as CVE-2023-0475), by introducing "(de)compression" bomb mitigation options to the various decompressors provided by this package. Specifically, FileSizeLimit and FilesLimit.
FileSizeLimit limits the size of a decompressed file, or limits the total size of all decompressed files if dealing with an archive.
FilesLimit limits the number of files that are allowed to be decompressed from an archive.
There are a few downsides to consider with the current approach I've taken before we merge this PR:
The limits are applied while the content is being decompressed. It doesn't do a "pre-flight check" before starting the decompression. So, if I had a limit of 15GB, an attacker would be able to consume up to that amount, but not past it.
io.LimitReader returns an EOF after the configured byte limit, and doesn't seem to provide a clear "you've read past the limit" error. In certain situations, this might lead to an unintended silent error.
☝️ To mitigate some of those issues, for the ZIP and TAR archives, I use the FileInfo in the header returned for the content to check the size before using it.
This PR aims to fix #407 (reserved as
CVE-2023-0475
), by introducing "(de)compression" bomb mitigation options to the various decompressors provided by this package. Specifically,FileSizeLimit
andFilesLimit
.FileSizeLimit
limits the size of a decompressed file, or limits the total size of all decompressed files if dealing with an archive.FilesLimit
limits the number of files that are allowed to be decompressed from an archive.There are a few downsides to consider with the current approach I've taken before we merge this PR:
io.LimitReader
returns anEOF
after the configured byte limit, and doesn't seem to provide a clear "you've read past the limit" error. In certain situations, this might lead to an unintended silent error.☝️ To mitigate some of those issues, for the ZIP and TAR archives, I use the
FileInfo
in the header returned for the content to check the size before using it.