oss-fuzz pointed out:
gd_gif_in.c:605:16: runtime error: index 5595 out of bounds for type 'int [4096]'
Add some bounds checking on each code that we read from the file.
oss-fuzz pointed out:
wbmp.c:48:14: runtime error: left shift of 253751679 by 7 places cannot be represented in type 'int'
See previous commit for more details.
oss-fuzz pointed out:
gd_io.c:174:10: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
See previous commit for more details.
oss-fuzz pointed out:
gd_io.c:139:14: runtime error: left shift of 199 by 24 places cannot be represented in type 'int'
Switch the temp var we use here to unsigned to avoid that. We do an
unsigned int to a signed int at the end which is undefined, but since
compilers don't seem to mind that, we won't care just yet. It also
makes the code match gdGetIntLSB behavior.
The palette headers always consist of 256 palette entries, and if
`\377\377\377\377` is given for the transparency, that means that there
is no transparent color.
The issue is that `gdImagePngCtxEx` (which is called by `gdImagePngPtr`
and the other PNG output functions to do the real work) does not return
whether it succeeded or failed, so this is not checked in
`gdImagePngPtr` and the function wrongly assumes everything is okay,
which is not, in this case, because the palette image contains no
palette entries.
We can't change the signature of `gdImagePngCtxEx` for API
compatibility reasons, so we introduce the static helper
`_gdImagePngCtxEx` which returns success respective failure, so
`gdImagePngPtr` and `gdImagePngPtrEx` can check the return value. We
leave it solely to libpng for now to report warnings regarding the
failing write.
CVE-2017-6362
We have to make sure to avoid alpha-blending issues by explicitly
switching to `gdEffectReplace` and to restore the old value afterwards.
We also document the algorithm used by `gdImageGrayScale()` and note
its limitations regarding palette images.
We have to initialize `trans_col` to the value that guards the call to
`gdImageColorTransparent()`. To avoid confusion, we replace the magic
numbers with a macro.
Although libgd is not really affected by this issue, because contrary
to PHP's bundled libgd it does not allow to read from negative offsets,
we consider it still a bug that `dynamicSeek()` does not behave like
`fileSeek()` with regard to negative positions.
As this behavior cannot be probed from outside, we omit the regression
test.
The stack allocated color map buffers were not zeroed before usage, and
so undefined palette indexes could cause information leakage.
This issue has been reported by Matviy Kotoniy to security@libgd.org in
<CAKm_7a-AO++B6cXYWM_DtycPENG5WNWK7NSEvQ5OmZziMY_JyA@mail.gmail.com>.
The following API functions now accept the font names and the text to be
printed as `const char*` rater than `char*`. This makes the functions
much more `C++` friendly.
gdImageStringFT();
gdImageStringTTF();
gdImageStringFTEx();
Other functions/types affected:
typeed struct fontkey_t;
any2eucjp();
gdTcl_UtfToUniChar();
DetectKanjiCode();
do_convert();
do_check_and_conv();
If the reading of GD2 images fails due to a truncated file, we have to
make sure that all resources are freed. We do so by going to `fail`
instead of bailing out early.
This is a minor issue, though, as GD2 isn't recommended for production
use at all.
Due to #82 the optimized support for reading 1 bps TIFF files (black &
white) had been disabled. Tony Lew already pointed out a fix in #88.
Furthermore, there was the following missing and improper error handling:
* TIFFReadScanline() returns -1 on error, not 0
* the result of TIFFReadTile() hasn't been checked
* in case of failure of these functions, the error had not been
propagated
We fix this, and re-enable direct support for 1 bps TIFFs, which is
more memory efficient than the general RGBA support. We also make sure
not to hit any not yet implemented code path.
GD2 stores the number of horizontal and vertical chunks as words (i.e. 2
byte unsigned). These values are multiplied and assigned to an int when
reading the image, what can cause integer overflows. We have to avoid
that, and also make sure that either chunk count is actually greater
than zero. If illegal chunk counts are detected, we bail out from
reading the image.
gdImageCreate() doesn't check for oversized images and as such is prone
to DoS vulnerabilities. We fix that by applying the same overflow check
that is already in place for gdImageCreateTrueColor().
CVE-2016-9317
It is possible to craft TGA files which will overflow the decompression
buffer, but not the image's bitmap. Therefore we also have to check for
potential decompression buffer overflows.
This issue had been reported by Ibrahim El-Sayed to security@libgd.org;
a modified case exposing an off-by-one error of the first patch had been
provided by Konrad Beckmann.
This commit is an amendment to commit fb0e0cce, so we use CVE-2016-6906
as well.
No need to decrease `u`, so we don't do it. While we're at it, we also factor
out the overflow check of the loop, what improves performance and readability.
This issue has been reported by Stefan Esser to security@libgd.org.
The issue is that gdImageWebpCtx() (which is called by gdImageWebpPtr() and
the other WebP output functions to do the real work) does not return whether
it succeeded or failed, so this is not checked in gdImageWebpPtr() and the
function wrongly assumes everything is okay, which is not, in this case,
because there is a size limitation for WebP, namely that the width and
height must by less than 16383.
We can't change the signature of gdImageWebpCtx() for API compatibility
reasons, so we introduce the static helper _gdImageWebpCtx() which returns
success respective failure, so gdImageWebpPtr() and gdImageWebpPtrEx() can
check the return value. We leave it solely to libwebp for now to report
warnings regarding the failing write.
This issue had been reported by Ibrahim El-Sayed to security@libgd.org.
CVE-2016-6912
tiff_invalid_read.tiff is corrupt, and causes an invalid read in
gdImageCreateFromTiffPtr(), but not in gdImageCreateFromTiff(). The culprit
is dynamicGetbuf(), which doesn't check for out-of-bound reads. In this case,
dynamicGetbuf() is called with a negative dp->pos, but also positive buffer
overflows have to be handled, in which case 0 has to be returned (cf. commit
75e29a9).
Fixing dynamicGetbuf() exhibits that the corrupt TIFF would still create
the image, because the return value of TIFFReadRGBAImage() is not checked.
We do that, and let createFromTiffRgba() fail if TIFFReadRGBAImage() fails.
This issue had been reported by Ibrahim El-Sayed to security@libgd.org.
CVE-2016-6911
It is possible to craft TGA files which will overflow the decompression
buffer, but not the image's bitmap. Therefore we augment the check for the
bitmap's overflow with a check for the buffer's overflow.
This issue had been reported by Ibrahim El-Sayed to security@libgd.org.
CVE-2016-6906
libgd clients need to be able to distinguish between fatal and
"extremely fatal" libjpeg and libpng errors, because in the former case
execution can proceed, but in the latter case libgd calls exit().
Therefore we report fatal errors as GD_WARNING.
Pull out the library versioning info out of configure and into a common
script that both cmake & autotools can run. This way we have a single
source of truth for the versioning info.
The buffer underflow happens at the start of the bitstream and after
each clear code, where the wrap-around is actually unnecessary. To
avoid the buffer underflow we simply initialize scd->last_byte to 2,
instead of adding further control logic to skip the relevant
assignments altogether.
We do not add a regression test, because the buffer underflow could
only be detected with ASAN or a similar memory-checker (or debugging),
and it happens for all proper GIFs anyway, so other tests (such as
tests/gif/gif_im2im) already exhibited the behavior.
We're passing `pixel1` as default color to `getPixelOverflow*()` for
pixels which may be outside the valid bounds. `pixel1` is supposed to
be always valid due to the fixed arithmetic's round towards zero
behavior.
Lossless WebP is a rather interesting alternative to PNG, and already
supported by `gdImageCreateFromWebp*()`, so we add support for
`gdImageWebp*()`, too.
We can stick with the existing API, using the quality parameter to
request lossless encoding if it is set to `gdWebpLossless`, which we
define to `PHP_INT` (to avoid adding a new dependency to gd.h, we hard-
code the value – we're assuming `sizeof(int)==4` anyway).
