A heap-based buffer overflow in _cairo_image_surface_create_from_jpeg() in extensions/cairo_io/cairo-image-surface-jpeg.c in GNOME gThumb before 3.8.3 and Linux Mint Pix before 2.4.5 allows attackers to cause a crash and potentially execute arbitrary code via a crafted JPEG file.
CVE: (none) => CVE-2019-20326
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20326 Also fixed in gthumb in Bug 26084.
CC: (none) => joequantAssignee: bugsquad => geiger.david68210Summary: pix security issue CVE-2019-20326 => pix new security issue CVE-2019-20326
i updated to the latest version of the 2.4 branch: src: pix-2.4.11-1.mga7
Assignee: geiger.david68210 => qa-bugsCC: (none) => mageia
Advisory: ======================== Updated pix 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 Linux Mint Pix before 2.4.5 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 ======================== Updated packages in core/updates_testing: ======================== pix-2.4.11-1.mga7 pix-devel-2.4.11-1.mga7 from pix-2.4.11-1.mga7.src.rpm
mga7, x64 Before updating: CVE-2019-20326 https://github.com/Fysac/CVE-2019-20326/blob/master/poc.min.jpg $ gthumb poc.min.jpg (gthumb:8793): Gtk-WARNING **: 08:20:07.933: Theme parsing error: gtk.css:2:33: Failed to import: Error opening file /home/lcl/.config/gtk-3.0/window_decorations.css: No such file or directory Gtk-Message: 08:20:07.954: Failed to load module "colorreload-gtk-module" gthumb: cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. Aborted (core dumped) Note that the warning message always occurs here with applications using Gtk. I always ignore it. After update: CVE-2019-20326 $ gthumb poc.min.jpg <Gtk warning ...> gthumb: cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. Aborted (core dumped) No change there. $ rpm -q pix pix-2.4.11-1.mga7 $ rpm -q pix-devel pix-devel-2.4.11-1.mga7 Is this expected to exit gracefully?
CC: (none) => tarazed25Keywords: (none) => feedback
Indeed, that looks bad.
Meanwhile, running gthumb without any apparent regressions. $ grep bin/pix gthumb.trace | egrep -v "local|rbenv" access("/usr/bin/pix", X_OK) = 0 stat("/usr/bin/pix", {st_mode=S_IFREG|0755, st_size=993888, ...}) = 0 access("/usr/bin/pix", X_OK) = 0 stat("/usr/bin/pix", {st_mode=S_IFREG|0755, st_size=993888, ...}) = 0 access("/usr/bin/pix", X_OK) = 0 stat("/usr/bin/pix", {st_mode=S_IFREG|0755, st_size=993888, ...}) = 0 .... Nothing else, apart from task-xapps, appears to need pix. So, all that is needed is an acknowledgement of a possible problem related to the patch. Otherwise there is no point in pushing this version.
Installed without issues. (média "Core Release") clutter-gtk-i18n 1.8.4 2.mga7 noarch clutter-i18n 1.26.2 3.mga7 noarch cogl-i18n 1.22.4 1.mga7 noarch lib64brasero-burn3_1 3.12.2 2.mga7 x86_64 lib64brasero-media3_1 3.12.2 2.mga7 x86_64 lib64brasero-utils3_1 3.12.2 2.mga7 x86_64 lib64clutter-gtk1.0_0 1.8.4 2.mga7 x86_64 lib64clutter1.0_0 1.26.2 3.mga7 x86_64 lib64cogl-pango20 1.22.4 1.mga7 x86_64 lib64cogl20 1.22.4 1.mga7 x86_64 lib64totem-plparser18 3.26.3 2.mga7 x86_64 totem-pl-parser-i18n 3.26.3 2.mga7 noarch (média "Core Updates Testing") pix 2.4.11 1.mga7 x86_64 I don't usually use pix so there may be some things that don't work as expected but after running and playing with it for a while, I didn't see any issues other than the output of lots of "CRITICAL" messages like those following. ** (pix:23454): CRITICAL **: 22:16:27.496: db__gth_browser_update_sensitivity_cb: assertion 'data != NULL' failed <MANY output lines like above> (pix:23454): GLib-CRITICAL **: 22:19:36.435: Source ID 27638 was not found when attempting to remove it It would be good if the above assertion failure could be solved so as not to flood the logs. Otherwise this gets an OK from me. System: Mageia 7, x86_64, Plasma DE, LXQt DE, Intel CPU, nVidia GPU using nvidia-current proprietary driver. $ uname -a Linux marte 5.10.11-desktop-1.mga7 #1 SMP Thu Jan 28 10:17:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q pix pix-2.4.11-1.mga7
CC: (none) => mageia
The fix seems to no really fix the issue... See Comment 4, Ping?
CC: (none) => ouaurelien
(In reply to Aurelien Oudelet from comment #8) > The fix seems to no really fix the issue... > See Comment 4, Ping? Re ping. We should fix this. @Packager can you take a look?
It does fix the issue in pix :-) gthumb is another package that needs a different update.
opened a new bug for gthumb https://bugs.mageia.org/show_bug.cgi?id=28401 Can you check if the bug is fixed in pix, and if so we can close this bug.
(In reply to Len Lawrence from comment #4) > mga7, x64 > > Before updating: > CVE-2019-20326 > https://github.com/Fysac/CVE-2019-20326/blob/master/poc.min.jpg > $ gthumb poc.min.jpg > After update: > CVE-2019-20326 > $ gthumb poc.min.jpg @Len, why using gthumb instead of pix in this issue? And does this M7 system fully updated because this is supposed to be fixed in Bug 26084 ?
@Joseph in reply to comments 10 and 11: pix does work without regressions but the PoC which is supposed to address the bug issue seems to indicate that it has not been fixed because the result of the test is SIGABORT before and after the update. Shall try this again on another system to double-check, later. @Aurelien re comment 12: I used gthumb because it was used in the published PoC. It looks like it is just a wrapper for pix. pix works, gthumb works. So maybe I SHOULD run the PoC with pix - doubt if it will make any difference.
(In reply to Len Lawrence from comment #13) > @Joseph in reply to comments 10 and 11: > pix does work without regressions but the PoC which is supposed to address > the bug issue seems to indicate that it has not been fixed because the > result of the test is SIGABORT before and after the update. > > Shall try this again on another system to double-check, later. > > @Aurelien re comment 12: > I used gthumb because it was used in the published PoC. It looks like it is > just a wrapper for pix. pix works, gthumb works. So maybe I SHOULD run the > PoC with pix - doubt if it will make any difference. That's make me nervious is that gthumb is supposed to be patched by Bug 26084... So, is it fully updated before doing tests ?
I see what you mean. The only way I can be certain just now is to rerun the update since I cannot remember which hardware I ran the original test on. Normally my system partitions are kept right up-to-date but it is always possible that something slipped through the cracks. So, starting again.....
OK. Have located the test system. $ rpm -q gthumb gthumb-3.7.2-2.1.mga7 $ rpm -q gthumb-devel gthumb-devel-3.7.2-2.1.mga7 $ pix poc.min.jpg Gtk-Message: 20:17:09.439: Failed to load module "colorreload-gtk-module" <The file is processed and an image produced.> However: $ gthumb poc.min.jpg Gtk-Message: 20:16:49.266: Failed to load module "colorreload-gtk-module" gthumb: cairo-surface.c:930: cairo_surface_reference: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. Aborted (core dumped) 1) The system appears to be fully updated with respect to gthumb. 2) pix handles the test file without aborting. 3) gthumb works for normal files. Unsure what conclusions to draw from that - does gthumb use its own code in the area affected by the bug or rely on pix?
Apologies to Joseph. Since pix handles the bad file OK we should send it on. Giving it an OK. Feel free to disagree.
Whiteboard: (none) => MGA7-64-OKKeywords: feedback => (none)
(In reply to Len Lawrence from comment #16) > OK. Have located the test system. > $ rpm -q gthumb > gthumb-3.7.2-2.1.mga7 > $ rpm -q gthumb-devel > gthumb-devel-3.7.2-2.1.mga7 > > $ pix poc.min.jpg > Gtk-Message: 20:17:09.439: Failed to load module "colorreload-gtk-module" > <The file is processed and an image produced.> > > However: > $ gthumb poc.min.jpg > Gtk-Message: 20:16:49.266: Failed to load module "colorreload-gtk-module" > gthumb: cairo-surface.c:930: cairo_surface_reference: Assertion > `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed. > Aborted (core dumped) > > 1) The system appears to be fully updated with respect to gthumb. > 2) pix handles the test file without aborting. > 3) gthumb works for normal files. > > Unsure what conclusions to draw from that - does gthumb use its own code in > the area affected by the bug or rely on pix? yeah, so pix is OK whereas gthumb is not OK, this is sad. Based on this, I'll reopen the Bug 26084.
Validating this, Advisory pushed to SVN.
Keywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0090.html
Status: NEW => RESOLVEDResolution: (none) => FIXED