Bug 26084 - gthumb new security issue CVE-2019-20326
Summary: gthumb new security issue CVE-2019-20326
Status: REOPENED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard:
Keywords:
: 28401 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-01-15 23:03 CET by David Walser
Modified: 2021-02-28 17:43 CET (History)
6 users (show)

See Also:
Source RPM: gthumb-3.7.2-2.mga7.src.rpm
CVE: CVE-2019-20326
Status comment:


Attachments

Description David Walser 2020-01-15 23:03:46 CET
Debian-LTS has issued an advisory on January 14:
https://lists.debian.org/debian-lts-announce/2020/01/msg00009.html
https://www.debian.org/lts/security/2020/dla-2066
https://security-tracker.debian.org/tracker/CVE-2019-20326

The issue is fixed upstream in 3.8.3 and the fix is linked from the last page above.
Comment 1 Lewis Smith 2020-01-16 20:59:54 CET
Assigning to you, Olav, as you have done several recent commits for this pkg which has no registered maintainer.

Assignee: bugsquad => olav

Comment 2 David GEIGER 2020-01-21 20:36:52 CET
Done for mga7!

CC: (none) => geiger.david68210

Comment 3 David Walser 2020-01-21 21:20:07 CET
Advisory:
========================

Updated gthumb packages fix security vulnerability:

A heap-based buffer overflow in _cairo_image_surface_create_from_jpeg() in
extensions/cairo_io/cairo-image-surface-jpeg.c in gThumb and Pix allows
attackers to cause a crash and potentially execute arbitrary code via a crafted
JPEG file (CVE-2019-20326).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20326
https://www.debian.org/lts/security/2020/dla-2066
========================

Updated packages in core/updates_testing:
========================
gthumb-3.7.2-2.1.mga7
gthumb-devel-3.7.2-2.1.mga7

from gthumb-3.7.2-2.1.mga7.src.rpm

Assignee: olav => qa-bugs

Comment 4 Herman Viaene 2020-01-22 15:30:48 CET
MGA7-64 Plasma on Lenovo B50
No installation issues
Ref to bug 24183 Comment 3 for testing
$ gthumb -s
displays a correct slideshow of all pictures in the pwd
$ gthumb DSCN0474.bmp 
Exrercised a few operations of gthumb (color contrast manually and automatic, color saturation, rotating, flipping)
All work OK

Whiteboard: (none) => MGA7-64-OK
CC: (none) => herman.viaene

Comment 5 Thomas Andrews 2020-01-22 19:04:43 CET
Validating. Advisory in Comment 3.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

Lewis Smith 2020-01-27 20:44:16 CET

Keywords: (none) => advisory

Comment 6 Mageia Robot 2020-01-28 08:54:31 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0056.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 7 Morgan Leijström 2020-06-16 19:06:10 CEST Comment hidden (obsolete)

CC: (none) => andresalaun

Comment 8 Lewis Smith 2020-06-16 20:32:10 CEST Comment hidden (obsolete)
Comment 9 David Walser 2020-06-16 22:42:49 CEST Comment hidden (obsolete)
Comment 10 Aurelien Oudelet 2021-02-21 20:06:26 CET
*** Bug 28401 has been marked as a duplicate of this bug. ***

CC: (none) => joequant

Comment 11 Aurelien Oudelet 2021-02-21 20:10:32 CET
Warning:

In bug 27908 for Mageia 7, gthumb seems affected by core dump also:
/7.1/SRPMS/core/updates/gthumb-3.7.2-2.1.mga7.src.rpm

BUT, update for CVE-2019-20326 was supposed fixed in gthumb with mga#26084.
But, Len Lawrence in Comment 4 of bug 27908 shows the opposite: a core dump with PoC. Warning. Reopening it if Len says his Mageia 7 was fully updated for Bug 27908.

CC: (none) => ouaurelien

Comment 12 Aurelien Oudelet 2021-02-22 10:27:16 CET
(In reply to David GEIGER from comment #2)
> Done for mga7!

(In reply to Herman Viaene from comment #4)
> MGA7-64 Plasma on Lenovo B50
> No installation issues
> Ref to bug 24183 Comment 3 for testing
> $ gthumb -s
> displays a correct slideshow of all pictures in the pwd
> $ gthumb DSCN0474.bmp 
> Exrercised a few operations of gthumb (color contrast manually and
> automatic, color saturation, rotating, flipping)
> All work OK

(In reply to Aurelien Oudelet from comment #11)
> Warning:
> 
> In bug 27908 for Mageia 7, gthumb seems affected by core dump also:
> /7.1/SRPMS/core/updates/gthumb-3.7.2-2.1.mga7.src.rpm
> 
> BUT, update for CVE-2019-20326 was supposed fixed in gthumb with mga#26084.
> But, Len Lawrence in Comment 4 of bug 27908 shows the opposite: a core dump
> with PoC. Warning. Reopening it if Len says his Mageia 7 was fully updated
> for Bug 27908.

This was supposed to be fixed. But, although normal operation within gthumb is OK, it seems the fix for it does not prevent an abort and a core dump according to Len's tests in Bug 27908. So, this needs a check to verify that how gthumb should handle the PoC in this bug.
Perhaps PoC was not available at time.

Re opening it, reassigning to who patches this.

Assignee: qa-bugs => geiger.david68210
Status: RESOLVED => REOPENED
CVE: (none) => CVE-2019-20326
Resolution: FIXED => (none)
Keywords: advisory, validated_update => (none)
Whiteboard: MGA7-64-OK => (none)

Aurelien Oudelet 2021-02-22 10:29:05 CET

CC: andresalaun => (none)

Comment 13 David GEIGER 2021-02-27 10:00:32 CET
So I update gthumb to the upstream release 3.8.3 which fixes really this security issue.
Comment 14 David Walser 2021-02-27 17:42:26 CET
Package list:
gthumb-3.8.3-1.mga7
gthumb-devel-3.8.3-1.mga7

from gthumb-3.8.3-1.mga7.src.rpm


Let's try the PoC again.

Assignee: geiger.david68210 => qa-bugs

Comment 15 Aurelien Oudelet 2021-02-28 17:43:47 CET
Mageia 7 Plasma x86_64, fully updated.

gthumb not installed.
# urpmi gthumb
This wants to install all of this... Why does it pulls also Pix?

gthumb-3.7.2-2.1.mga7.x86_64                  Sun Feb 28 17:14:26 2021
totem-pl-parser-i18n-3.26.3-2.mga7.noarch     Sun Feb 28 17:14:25 2021
pix-2.0.3-2.mga7.x86_64                       Sun Feb 28 17:14:25 2021
memphis-0.2.3-15.mga7.x86_64                  Sun Feb 28 17:14:25 2021
lib64totem-plparser18-3.26.3-2.mga7.x86_64    Sun Feb 28 17:14:25 2021
lib64memphis0.2_0-0.2.3-15.mga7.x86_64        Sun Feb 28 17:14:25 2021
lib64cogl20-1.22.4-1.mga7.x86_64              Sun Feb 28 17:14:25 2021
lib64cogl-pango20-1.22.4-1.mga7.x86_64        Sun Feb 28 17:14:25 2021
lib64clutter1.0_0-1.26.2-3.mga7.x86_64        Sun Feb 28 17:14:25 2021
lib64clutter-gtk1.0_0-1.8.4-2.mga7.x86_64     Sun Feb 28 17:14:25 2021
lib64champlain0.12_0-0.12.19-2.mga7.x86_64    Sun Feb 28 17:14:25 2021
lib64champlain-gtk0.12_0-0.12.19-2.mga7.x86_64 Sun Feb 28 17:14:25 2021
lib64brasero-utils3_1-3.12.2-2.mga7.x86_64    Sun Feb 28 17:14:25 2021
lib64brasero-media3_1-3.12.2-2.mga7.x86_64    Sun Feb 28 17:14:25 2021
lib64brasero-burn3_1-3.12.2-2.mga7.x86_64     Sun Feb 28 17:14:25 2021
cogl-i18n-1.22.4-1.mga7.noarch                Sun Feb 28 17:14:25 2021
clutter-i18n-1.26.2-3.mga7.noarch             Sun Feb 28 17:14:25 2021
clutter-gtk-i18n-1.8.4-2.mga7.noarch          Sun Feb 28 17:14:25 2021

$ rpm -qa | grep gthumb
gthumb-3.7.2-2.1.mga7
ffmpegthumbs-19.04.0-1.mga7

CVE-2019-20326
https://github.com/Fysac/CVE-2019-20326/blob/master/poc.min.jpg

$ gthumb poc.min.jpg
gthumb: cairo-surface.c :930 : cairo_surface_reference:  l'assertion « CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count) » a échoué.
Abandon (core dumped)

So applying update with QA Repo:
(média « QA Testing (64-bit) »)
  gthumb                         3.8.3        1.mga7        x86_64

BUT: If I use local=C
$ LANG=C gthumb ./Téléchargements/poc.min.jpg 

** (gthumb:18198): CRITICAL **: 17:26:59.745: Failed to parse arguments: Invalid byte sequence in conversion input

This seems to exit gracefully whereas if it uses my locale setting (fr_FR.UTF-8):

$ gthumb ./Téléchargements/poc.min.jpg 
gthumb: cairo-surface.c :930 : cairo_surface_reference:  l'assertion « CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count) » a échoué.
Abandon (core dumped)

Same as before.
Note that pix that is installed with update from Bug 27908 does not exit and seems to display a 1px by 33000px JPEG file from poc.min.jpg

So. This is not user-friendly that gthumb does this.

But, in journal while doing this, there is no coredump/segfault. So gthumb seems to exit gracefully...
Hum,
$ gdb gthumb
(gdb) run
Starting program: /usr/bin/gthumb 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5b3d700 (LWP 25579)]
[New Thread 0x7ffff4885700 (LWP 25580)]
[New Thread 0x7fffed3ff700 (LWP 25583)]
[New Thread 0x7fffd62a9700 (LWP 25587)]
[New Thread 0x7fffd5a89700 (LWP 25588)]
gthumb: cairo-surface.c :930 : cairo_surface_reference:  l'assertion « CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count) » a échoué.

Thread 6 "pool-gthumb" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd5a89700 (LWP 25588)]
0x00007ffff6c169ba in raise () from /lib64/libc.so.6

Leaving this for other advice...

Note You need to log in before you can comment on or make changes to this bug.