#947478 freeimage: CVE-2019-12214

Package:
src:freeimage
Source:
freeimage
Submitter:
Moritz Muehlenhoff
Date:
2024-04-15 18:39:02 UTC
Severity:
important
Tags:
#947478#10
Date:
2019-05-26 20:01:40 UTC
From:
To:
Hi Moritz,

thanks for the reporting. As far as I see, there is still
no available fix from upstream.

Cheers

Anton

Am So., 26. Mai 2019 um 21:27 Uhr schrieb Moritz Muehlenhoff <jmm@debian.org>:
#947478#21
Date:
2019-05-27 21:01:14 UTC
From:
To:
CVE-2019-12214 does not affect buster and stretch.
Jessie should be double checked because an older
version is used there.

Anton

Am So., 26. Mai 2019 um 22:01 Uhr schrieb Anton Gladky <gladk@debian.org>:
#947478#26
Date:
2019-06-03 18:23:27 UTC
From:
To:
There is no upstream fix still available.

I am planning to decrease the severity of
the ticket to normal and track it as a simple
security issue.

Anton

Am Mo., 27. Mai 2019 um 23:01 Uhr schrieb Anton Gladky <gladk@debian.org>:
#947478#31
Date:
2019-06-04 18:20:33 UTC
From:
To:
severity 929597 important
thanks

The fix from upstream is still not available. I am not feeling
confident enough to provide a fix for this complex peace
of code without breaking it.

Also reducing the severity. If the security team decides to
keep it "grave" - feel free to revert it.

Regards


Anton

Am Mo., 3. Juni 2019 um 20:23 Uhr schrieb Anton Gladky <gladk@debian.org>:
#947478#38
Date:
2019-06-04 20:43:50 UTC
From:
To:
Fine, but we still need to fix it once properly fixed upstream.

Cheers,
        Moritz
#947478#43
Date:
2019-07-07 12:25:00 UTC
From:
To:
Still no updates from upstream....

Anton
#947478#48
Date:
2019-09-30 19:05:03 UTC
From:
To:
No activity from upstream.

Anton
#947478#53
Date:
2019-09-30 19:44:53 UTC
From:
To:
Are they still alive upstream? Do you have a cance to ping some
upstream people directly to make them aware of the issue via anothe
channel?

Regards,
Salvatore
#947478#58
Date:
2019-09-30 19:56:07 UTC
From:
To:
Last commit was in April 2019. We should really think
about existing this package in the Debian.

Anton

Am Mo., 30. Sept. 2019 um 21:44 Uhr schrieb Salvatore Bonaccorso
<carnil@debian.org>:
#947478#63
Date:
2019-09-30 20:10:28 UTC
From:
To:
Hi,

You mean with "think about existing this package in the Debian" about
a potential removal from Debian? A removal, considering the affected
reverse (build-)depdendencies does not seem realistic at the
moment[1].

Regards,
Salvatore

 [1] dak rm --suite=sid -n -R freeimage on respighi would list a lot
 of broken Build-Depends and broken Depends.
#947478#68
Date:
2019-10-26 14:11:29 UTC
From:
To:
Hi,

The overflow happens during the following call to memcpy:

    // convert to strip
    if(x + tileWidth > width) {
            src_line = imageRowSize - rowSize;
    } else {
            src_line = tileRowSize;
    }
    BYTE *src_bits = tileBuffer;
    BYTE *dst_bits = bits + rowSize;
    for(int k = 0; k < nrows; k++) {
            memcpy(dst_bits, src_bits, src_line);
            src_bits += tileRowSize;
            dst_bits -= dst_pitch;
    }

This portion of code copies image data from a libTIFF-provided buffer to an
internal buffer. The overflow happens because src_line is larger than the
size of dst_bits.

This is the result of an inconsistency between libTIFF and freeimage:

In the libTIFF case, tile row size is
= samplesperpixel * bitspersample * tilewidth / 8
= bitsperpixel * tilewidth / 8
= 6 * 32 * 7 / 8 = 168

In the freeimage case, tile row size is
bitsperpixel * tilewidth / 8
= 32 * 7 / 8 = 28

As a result, the two buffers are differently sized.

freeimage has a bpp of 32 because CreateImageType calls
FreeImage_AllocateHeader with MIN(bpp, 32).

This 'MIN(bpp, 32)' looks like a terrible hack to me, but we can't change
it to 'bpp' because FIT_BITMAP images with bpp > 32 does not seem to be
supported by freeimage. Also, in this case, bpp > 32 doesn't even make
sense:

Looking closely at the reproducer, we can notice that it defines a bilevel
image with samplesperpixel and bitspersample parameters, both unexpected in
bilevel images.

Pixels in bilevel images can either be black or white. There is as such
only one sample per pixel, and a single bit per sample is sufficient.  The
spec defines bpp = 8. It is unclear whether the specification allows for
arbitrary values of bitspersample or samplesperpixel (extrasamples?) in
this case.

This file gets rejected by most libTIFF tools.

# patch

+ add check to CreateImageType() to reject FIT_BITMAP images with bpp > 32
  instead of passing MIN(bpp, 32).
+ change type of dst_pitch to unsigned
+ call memcpy with MIN(dst_pitch, src_line) instead of src_line. this will
  help overcome any further (future) discrepancy between libTIFF and
  freeimage.

# tests

I have tested for regressions with the following samples, using a modified
version of Examples/Linux/linux-gtk.c:

http://www.simplesystems.org/libtiff/images.html

During these tests, I found other issues with bilevel images, unrelated to
this patch. I will try to take a look at them in the future.

I can provide additional explanations if there is anything unclear.

I'd like to get this patch peer-reviewed/merged upstream before shipping
it in a Debian release.

regards,
Hugo
#947478#73
Date:
2019-10-26 18:40:53 UTC
From:
To:
Thanks, Hugo, for analyzing the issue in details and proposing the fix.

Do you want to add the patch into the corresponding forum-thread
in freeimage website?

Regards

Anton

Am Sa., 26. Okt. 2019 um 16:11 Uhr schrieb Hugo Lefeuvre <hle@debian.org>:
#947478#78
Date:
2019-11-03 08:23:31 UTC
From:
To:
Hi Anton,

yes, I have just forwarded my message to the SF thread. Let's hope upstream
will find some time to take a look at it.

cheers,
Hugo
#947478#83
Date:
2019-11-23 09:25:06 UTC
From:
To:
Hi,

Upstream seems to have merged my patch along with some more changes
regarding CVE-2019-12213[0].

I am planning to take a look at this patch and release a DLA for jessie.

The security team is also planning to release a DSA for stretch and buster.
I am already working on a jessie upload, so I should also be able to handle
stretch and buster.  Anton, you know this package better than me, would you
be available to test the update?

thanks!

regards,
Hugo

[0] https://sourceforge.net/p/freeimage/svn/1825/
#947478#88
Date:
2019-11-23 14:08:48 UTC
From:
To:
Hello Hugo,

thanks for update!
I am also not an expert in the package, but sure, I will try to do it.

Regards

Anton

Am Sa., 23. Nov. 2019 um 10:25 Uhr schrieb Hugo Lefeuvre <hle@debian.org>:
#947478#93
Date:
2019-12-11 14:03:41 UTC
From:
To:
Hi,

small update:

I have updated jessie with the cherry picked patch for CVE-2019-12213 and
CVE-2019-12211.

I have contacted upstream to know when he is planning to release 3.18.1 so
that we can get this fixed in testing without cherry picking.

I am currently testing stretch and buster updates with the cherry picked
patch.

cheers,
Hugo
#947478#98
Date:
2019-12-27 15:13:57 UTC
From:
To:
Hi,

As there will not be a fix for all CVEs in one go, let's split the bug
for the benefit of tracking the fixes. CVE-2019-12211 and
CVE-2019-12213  have the same upstream change, so will clone this into
three.

Regards,
Salvatore
#947478#107
Date:
2024-04-15 18:04:42 UTC
From:
To:
Information about this CVE and bug.


Hi,

I've performed a more thoroughful investigation and have informed NIST
that the offending line is actually to be found in openjpeg between
version 2.0.0 up to (excluding) 2.1.0.

Debian Buster isn't affected as it uses version 2.3.0-2+deb10u2.

Hereunder copy of the email I've sent ot NIST.

Best regards,

Cyrille
)
.

Le samedi 13 avril 2024 à 09:56 +0200, Cyrille a écrit :