Update libmspack to 0.10.1alpha
2019-02-18 Stuart Caie <kyzer@cabextract.org.uk> * chmd_read_headers(): a CHM file name beginning "::" but shorter than 33 bytes will lead to reading past the freshly-allocated name buffer - checks for specific control filenames didn't take length into account. Thanks to ADLab of Venustech for the report and proof of concept. 2019-02-18 Stuart Caie <kyzer@cabextract.org.uk> * chmd_read_headers(): CHM files can declare their chunks are any size up to 4GB, and libmspack will attempt to allocate that to read the file. This is not a security issue; libmspack doesn't promise how much memory it'll use to unpack files. You can set your own limits by returning NULL in a custom mspack_system.alloc() implementation. However, it would be good to validate chunk size further. With no offical specification, only empirical data is available. All files created by hhc.exe have a chunk size of 4096 bytes, and this is matched by all the files I've found in the wild, except for one which has a chunk size of 8192 bytes, which was created by someone developing a CHM file creator 15 years ago, and they appear to have abandoned it, so it seems 4096 is a de-facto standard. I've changed the "chunk size is not a power of two" warning to "chunk size is not 4096", and now only allow chunk sizes between 22 and 8192 bytes. If you have CHM files with a larger chunk size, please send them to me and I'll increase this upper limit. Thanks to ADLab of Venustech for the report. 2019-02-18 Stuart Caie <kyzer@cabextract.org.uk> * oabd.c: replaced one-shot copying of uncompressed blocks (which requires allocating a buffer of the size declared in the header, which can be 4GB) with a fixed-size buffer. The buffer size is user-controllable with the new msoab_decompressor::set_param() method (check you have version 2 of the OAB decompressor), and also controls the input buffer used for OAB's LZX decompression. Reminder: compression formats can dictate how much memory is needed to decompress them. If memory usage is a security concern to you, write a custom mspack_system.alloc() that returns NULL if "too much" memory is requested. Do not rely on libmspack adding special heuristics to know not to request "too much". Thanks to ADLab of Venustech for the report.
This commit is contained in:
parent
af5ce6e79b
commit
fa17f017cc
2 changed files with 7 additions and 7 deletions
|
@ -1,6 +1,6 @@
|
|||
# $NetBSD: Makefile,v 1.6 2018/12/01 06:01:12 wiz Exp $
|
||||
# $NetBSD: Makefile,v 1.7 2019/08/05 13:39:24 prlw1 Exp $
|
||||
|
||||
DISTNAME= libmspack-0.9.1alpha
|
||||
DISTNAME= libmspack-0.10.1alpha
|
||||
CATEGORIES= devel
|
||||
MASTER_SITES= https://www.cabextract.org.uk/libmspack/
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
$NetBSD: distinfo,v 1.6 2018/12/01 06:01:12 wiz Exp $
|
||||
$NetBSD: distinfo,v 1.7 2019/08/05 13:39:24 prlw1 Exp $
|
||||
|
||||
SHA1 (libmspack-0.9.1alpha.tar.gz) = 15f8eac22372d487857220b0d0e8035f2efe2657
|
||||
RMD160 (libmspack-0.9.1alpha.tar.gz) = 955c54ddce2440b24919895a77c937934c540cc6
|
||||
SHA512 (libmspack-0.9.1alpha.tar.gz) = 4e39c2be8768c5c0b0d0798c9322ff022173f5e05af1636c18541bbc9f58c1ae1af59252d5631340fca601495c5b1e5abed0ad83481387421d2df5efb75cd49a
|
||||
Size (libmspack-0.9.1alpha.tar.gz) = 494651 bytes
|
||||
SHA1 (libmspack-0.10.1alpha.tar.gz) = 82a6a102a2422d4d61bdd00f059bd3978409ca5f
|
||||
RMD160 (libmspack-0.10.1alpha.tar.gz) = 8e627c0666ad969ff3bc5e62a609ad7d26dc780b
|
||||
SHA512 (libmspack-0.10.1alpha.tar.gz) = a7b5f7caa49190c5021f3e768b92f2e51cc0ce685c9ab6ed6fb36de885c73231b58d47a8a3b5c5aa5c9ac56c25c500eb683d84dbf11f09f97f6cb4fff5adc245
|
||||
Size (libmspack-0.10.1alpha.tar.gz) = 963274 bytes
|
||||
|
|
Loading…
Reference in a new issue