Bug#1040945: tiff: CVE-2023-3618

[Salvatore Bonaccorso]

Source: tiff
Version: 4.5.1-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/libtiff/libtiff/-/issues/529
X-Debbugs-Cc: car...@debian.org, Debian Security Team <te...@security.debian.org>

Hi,

The following vulnerability was published for tiff.

CVE-2023-3618[0]:
| A flaw was found in libtiff. A specially crafted tiff file can lead
| to a segmentation fault due to a buffer overflow in the Fax3Encode
| function in libtiff/tif_fax3.c, resulting in a denial of service.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3618
https://www.cve.org/CVERecord?id=CVE-2023-3618
[1] https://gitlab.com/libtiff/libtiff/-/issues/529

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

[László Böszörményi]

Hi Salvatore,

On Wed, Jul 12, 2023 at 9:39 PM Salvatore Bonaccorso <car...@debian.org> wrote:
> Source: tiff
> Version: 4.5.1-1

> CVE-2023-3618[0]:
> | A flaw was found in libtiff. A specially crafted tiff file can lead
> | to a segmentation fault due to a buffer overflow in the Fax3Encode
> | function in libtiff/tif_fax3.c, resulting in a denial of service.

[...]

> Please adjust the affected versions in the BTS as needed.

Done my quick testing. My experience is the following.
1) libtiff6 and libtiff-tools are both 4.5.1-1 (ie, Trixie): the tool
reports several warnings, exists with 1 (non-zero) but doesn't
segfault. Even tried with valgrind, still no segfault.
2) libtiff6 is 4.5.1-1 backported to Bookworm and libtiff-tools are
not, ie it's 4.5.0-6 : the tool reports the same warnings like above,
but this time it _does_ segfault.
3) If libtiff-tools also updated to 4.5.1-1 on Bookworm: it's like the
first case, several warnings, non-zero exit code without a segfault.

In short, it seems:
- it's a non-dsa as only a crash in a CLI tool (which has end of life now),
- doesn't affect the library,
- while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable,
4.5.1-1 fixed this issue.

But you may find it otherwise, I do not alter this report in the BTS.

Regards,
Laszlo/GCS

[Salvatore Bonaccorso]

Hi László,

Thanks for coming back that quickly, impressive :).

I do completely agree, it's a no-dsa issue similar to the others, was
done already.

For about having the issue fixed: The problem I have is that upstream
has not yet closed the issue. Is it completely fixed and what is the
fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is
slight unhelpful on that front.

Are you able to identify the fixing commit confirming it is done in
4.5.1-1?

Regards,
Salvatore

[László Böszörményi]

Hi Salvatore,

On Thu, Jul 13, 2023 at 8:42 PM Salvatore Bonaccorso <car...@debian.org> wrote:
> On Wed, Jul 12, 2023 at 10:12:50PM +0200, László Böszörményi wrote:
> > In short, it seems:
> > - it's a non-dsa as only a crash in a CLI tool (which has end of life now),
> > - doesn't affect the library,
> > - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable,
> > 4.5.1-1 fixed this issue.
> >
> > But you may find it otherwise, I do not alter this report in the BTS.

[...]

> For about having the issue fixed: The problem I have is that upstream
> has not yet closed the issue. Is it completely fixed and what is the
> fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is
> slight unhelpful on that front.

Reason is simple. Upstream was fixing issues and probably was doing
as they wanted. That is, there's another SIGSEGV issue [1] and it's in
tiffcrop as well. Upstream fixed it and was going on with other fixes.
Then maybe they couldn't reproduce the mentioned CVE issue and went on
releasing v4.5.1 with several other CVE fixes [2]. There Timothy
Lyanguzov commented that bug#529 probably will get a CVE id too, but
he couldn't reproduce it with that Git HEAD.
Answer is simple, the other SIGSEGV issue [1] fix solved this issue as
well. As upstream probably didn't recognize and couldn't reproduce
this SIGSEGV (anymore), it remained open.

> Are you able to identify the fixing commit confirming it is done in
> 4.5.1-1?

Indeed, it is fixed for 4.5.1 and the fixing commit is
b5c7d4c4e03333ac16b5cfb11acaaeaa493334f8 [3].

Hope this clear things up,
Laszlo/GCS
[1] https://gitlab.com/libtiff/libtiff/-/issues/553
[2] https://gitlab.com/libtiff/libtiff/-/issues/533
[3] https://gitlab.com/libtiff/libtiff/-/commit/b5c7d4c4e03333ac16b5cfb11acaaeaa493334f8

[Salvatore Bonaccorso]

Hi László

Many thanks, this outline was quite helpful. I have updated the
security-trcker metadata.

Regards,
Salvatore