CVE-2017-1000126 is a Stack out of bounds read in the WebP parser caused by the
parameter size & filesize being too large, causing the parser to land in an
infinite loop and eventually crash. Enforcing that the size over which the
parser iterates is smaller than the file fixes this issue.
This fixes#175.
The webp header contains the filesize of the image starting at the 8th byte in
bytes 4 to 8 encoded as a little endian 32 bit unsigned integer. The code was
erroneously assuming that the extracted filesize is starting at the 12th byte,
i.e. at the end of the WebP file header.
Source: https://developers.google.com/speed/webp/docs/riff_container
enforce is a function comparable to assert(), it ensures that a condition is
true. However, while assert() should be used for conditions where we can be
certain that they are true, enforce is intended to be used for conditions that
can fail (like on invalid input). Therefore enforce() throws an exception when
the condition is false and does not abort the program's execution. Also, it is
not turned off by defining NDEBUG.
- add a new file enforce.hpp
- implement enforce()
* Update dependency on libexpat to version 2.2.5
This new version of the conan recipe contain packages for new compilers
* Get gtest and libcurl from bincrafters
* Update the zlib dependency
* Use clang-5.0
- templated structs were not required, SFINAE works for functions too
=> use instead, removes some unneeded code
- fix non-usage of builtins with clang
- adjust unit tests
The fallback signed integer overflow check is quite expensive, but the addition
can be safely performed when saved in an int due to integer promotion
rules. This makes the check a little less expensive.
- cdataBuf must be at least 8 bytes long otherwise decodeIHDRChunk
reads out of bounds
- pngImage::readMetadata now skips png chunks where the offset for
IHDR chunks is invalid
- added assertion into PngChunk::decodeIHDRChunk() to ensure dataBuf
size
When parsing a subBox that is a ColorHeader, a length is extracted
from the input file and fed directly into DataBuf() (which calls
malloc). A crafted input file can provide arbitrarily (up to
max(uint32_t)-8) large values and result in excessive memory
allocation.
This commit adds a check for the new size of DataBuf so that it is not
larger than the remaining size of the file.
This fixes#202 aka CVE-2018-4868
Dan Čermák
D4N
HumanDynamo
Luis Díaz Más
Robin Mills
Fredrik lingvall
Fredrik Lingvall