- Define STRERROR_R_CHAR_P properly on CMake and use it on futils.cpp
- We use now _GNU_SOURCE to determine which version of strerror_r to use
- strError only throws if ret==ERANGE
- Remove STRERROR_R_CHAR_P. It has been never used
- sort defines in config.h.cmake
- Remove EXV_HAVE_DECL_STRERROR_R that is not used anymore
- Remove EXV_HAVE_STRERROR. C++98 always will have it
Pimpl class Impl is stored in raw pointers which are allocated on the heap in
the constructor. However, the constructor can throw an exception resulting in a
memory leak as the destructor is **not** invoked.
=> A smart pointer is however properly deallocated.
We also changed the way in which we copy the DLLs to the bin folder inside the build directory.
Before we were directly placing the conan-deps DLLs into the bin folder directly. Now we place
them into a directory called conanDlls, and from there we copy them to bin or install/bin
at build and install steps respectively.
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()
- 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
- consider that key is advanced by 8 bytes if stripHeader is true
=> length is reduced by same amount
Fixed by adding offset to the check in the loop
- Rewrote loop so that keysize is checked before the next
iteration (preventing an out of bounds read)
This change define explicitly the behavior that exiv2::getEnv should have
on response to unexpected inputs.
There are some other minor changes:
- Use _putenv_s for the unit tests on Windows
- Add todo comment
- Remove deprecated note about freeing memory
This commit adds a out-of-bounds protection in the case that the
extracted values for offset & count are summed up larger than the size
of the file. Also this function checks for overflows before performing
the addition.
This fixes#159
The invalid memory dereference in
Exiv2::getULong()/Exiv2::StringValueBase::read()/Exiv2::DataValue::read()
is caused further up the call-stack, by
v->read(pData, size, byteOrder) in TiffReader::readTiffEntry()
passing an invalid pData pointer (pData points outside of the Tiff
file). pData can be set out of bounds in the (size > 4) branch where
baseOffset() and offset are added to pData_ without checking whether
the result is still in the file. As offset comes from an untrusted
source, an attacker can craft an arbitrarily large offset into the
file.
This commit adds a check into the problematic branch, whether the
result of the addition would be out of bounds of the Tiff
file. Furthermore the whole operation is checked for possible
overflows.
A heap buffer overflow could occur in memcpy when icc.size_ is larger
than data.size_ - pad, as then memcpy would read out of bounds of data.
This commit adds a sanity check to iccLength (= icc.size_): if it is
larger than data.size_ - pad (i.e. an overflow would be caused) an
exception is thrown.
This fixes#71.
Source:
https://github.com/Exiv2/exiv2/issues/57#issuecomment-333086302
tc can be a null pointer when the TIFF tag is unknown (the factory
then returns an auto_ptr(0)) => as this can happen for corrupted
files, an explicit check should be used because an assertion can be
turned of in release mode (with NDEBUG defined)
This also fixes#57
At least the musl libc on Linux has the same issue as Mac OS X: the
PTHREAD_RECURSIVE_* static initialiser does not exist. This is a
documented and purposeful omission:
http://www.openwall.com/lists/musl/2017/02/20/3
This commit uses similar logic to the Apple test on other Unixes.
=> Should fix#76 (most of the work has been done by Robin Mills in
6e3855aed7)
The problem with #76 is the contents of the 26th IFD, with the
following contents:
tag: 0x8649
type: 0x1
count: 0xffff ffff
offset: 0x4974
The issue is the size of count (uint32_t), as adding anything to it
causes an overflow. Especially the expression:
(size*count + pad+20)
results in an overflow and gives 20 as a result instead of
0x100000014, thus the condition in the if in the next line is false
and the program continues to run (until it crashes at io.read).
To properly account for the overflow, the brackets have to be removed,
as then the result is saved in the correctly sized type and not cast
after being calculated in the smaller type.
The brackets have also been removed from bigtiffimage.cpp, where the
same issue is present.
Dan Čermák
Luis Díaz Más
Robin Mills
HumanDynamo
Fredrik lingvall
Fredrik Lingvall
Michał Walenciak
tbeu
Andreas Sturmlechner
A. Wilcox