[CVE-2019-20326] gthumb crashes when trying to load an image with a height above 32767 px (heap-based buffer overflow)

[Joshua Peisach]

[For some reason, the autoreporter wasn't opening Launchpad so I'm bugging this manually]

CVE-2019-20326 - if gThumb tries to load an image greater than Cairo's max drawing size, it will crash. This is a heap-based buffer overflow an attacker could execute harmful code.

Fysac on GitHub made a good writeup about this - https://github.com/Fysac/CVE-2019-20326

I have a patch for 20.04 Focal.

[Impact]

 * When gthumb opens or the user tries to open larger than 32767 px, it overflows Cairo's max image size. Thus, a heap buffer overflow crashes gthumb.

 * An attacker could use this to execute arbitrary code.

[Test Plan]

 * Get or craft a JPEG image that has a height larger than 32767 pixels.

 * Clone this repo if you need the image: https://github.com/Fysac/CVE-2019-20326

 * Open it in gthumb, or just run 'gthumb poc.min.jpg'

[Where problems could occur]

 * The code is in C - a great time for other regressions to open (thanks NULL)

 * If an update is made to the cairo library, this can break the patch and break
 gthumb; not only this patch but the software as a whole

 * This issue may still be reproducible across other formats - png, svg, etc.

 * The type of image rendering may still make this vulnerable (see how the buffer was fixed every case in the patch)

[Additional commit needed]

 * This patch alone does not fix the issue; it does prevent heap-buffer overflow but still results in gthumb crashing.
  gthumb: ../../../../src/cairo-surface.c:930: cairo_surface_reference: Assertion 'CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count)' failed.

 * A trivial fix I found for this was in gth_image_set_cairo_surface() to remove the call to _gth_image_free_data (https://gitlab.gnome.org/GNOME/gthumb/-/blob/gthumb-3-8/gthumb/gth-image.c). This would make prevent the crash (not remove the data in image->priv->data) but then other parts of GTK's drawing seems to freak out.

 * An appropriate fix for this would be https://gitlab.gnome.org/GNOME/gthumb/-/commit/9729b8688d5d67c01deabea46ad469ec517250c5.

 * Applying this fix allows for a greater risk of regression.
 * If the value for whether gthumb is finished loading the jpeg is not finished, gthumb will set the value to 'finished' anyways. Then it proceeds to other cairo surface NULL checks.

 * This would just have Gtk set an error and call it a day. (line 607 in the commit mentioned above).

[Other Info]

 * Desktop, ubuntu 20.04
 * Not sure if I want to do Ubuntu 18.04, but cinnamon users may use gthumb so for ubuntu cinnamon i feel like its important and 20.04 its still in service for UCR

 * I think it's possible that this may occur throughout other types of image formats with the same setup. This may be reproducible on png's.

 ** There has been LOTS of stability commits and fixes for gthumb upstream; especially near the gthumb 3.8.3 release. It may be good if I later come back to fix them after this.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gthumb 3:3.8.0-2.1build1
ProcVersionSignature: Ubuntu 5.13.0-46.51~20.04.1-generic 5.13.19
Uname: Linux 5.13.0-46-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: X-Cinnamon
Date: Sun May 29 12:20:58 2022
InstallationDate: Installed on 2021-11-24 (185 days ago)
InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210826)
SourcePackage: gthumb
UpgradeStatus: No upgrade log present (probably fresh install)

[Joshua Peisach (itzswirlz)]

focal patch

[Fabian Toepfer (fabiantoepfer)]

Hi Joshua, thank you for the patch. The package is also vulnerable to CVE-2020-36427, would you like to address this issue as well and include it in your patch?

[Joshua Peisach (itzswirlz)]

Hi Fabian - sorry for late response!

This patch is not complete. I've been trying everything before.. giving up and I will eventually come back; the app would still crash. Using gdb I traced back to a pointer where some memory was freed that contains the image that is shown but then the rest of the Gtk UI glitches out. I guess I need to test on other devices, since it could be a graphics issue but it is not complete and I need to reach out to gthumb maintainers.

I'll look at CVE-2020-36427. For now, don't submit this to -proposed yet

[Fabian Toepfer (fabiantoepfer)]

Hi Joshua, thank you for your reply! As far as I looked into it, after applying your patch, the reproducer (poc.min.jpg) no longer triggers the heap overflow, but as you said, causes an assertion error. After applying the patch for CVE-2020-36427 (https://gitlab.gnome.org/GNOME/gthumb/-/commit/9729b8688d5d67c01deabea46ad469ec517250c5) which is related to this issue https://gitlab.gnome.org/GNOME/gthumb/-/issues/106, the attached reproducer (20200704_174327.jpg.bin) no longer causes the assertion error and displays correctly after the patch. Also no assertion error for poc.min.jpg. So after applying both patches, the app no longer crashes for both images, but I also experience these weird graphical UI glitches when opening poc.min.jpg. Please let me know if you are going to further analyze this issue.

[Fabian Toepfer (fabiantoepfer)]

I did a bisect and found this commit https://gitlab.gnome.org/GNOME/gthumb/-/commit/ea9415a703097f805ba227fedda908dfe72c4e90 which fixes the ui glitches for me. Please let me know if it works for you and if you are going to update your patch.

[Joshua Peisach (itzswirlz)]

Hi Fabian - the commit https://gitlab.gnome.org/GNOME/gthumb/-/commit/9729b8688d5d67c01deabea46ad469ec517250c5 I did try at home.. but it didn't work for me. I'll definitely try the one you listed although I think I might have tried it but I thought it was already applied.. bisecting it was driving me crazy lol. I would also have to free that pointer that caused the image to crash (that lead me to the ui glitches) which might be memory leak regression potential.. that worries me but I'll do more analysis

I'm on vacation right now so all i have is my laptop with 22.04. Can't do much testing and on a 8 GB RAM machine with an i5, VM won't be feasible to work with.

[Fabian Toepfer (fabiantoepfer)]

If you have any other images that reproduce the bugs, please feel free to share them. I tested the app with address sanitizer enabled and could not find any more issues when opening the images, so it looks okay for me.

[Fabian Toepfer (fabiantoepfer)]

Hey Joshua, just a small reminder - are you going to further work on this issue?

[Joshua Peisach (itzswirlz)]

Hi Fabian,

Of course, because I am me I forgot. I'm going to take another look at it; I think I tested it again or something happened and I lost my progress and despite being on a super slow machine (the old iMac I use with 20.04), I'm going to try again.

I'm first going to try testing it raw - just injecting the commits and their patches, but not saving them to debian/patches until I can confirm it actually is working.

By the way, I hope you know about the "scan-build" tool as along the way this process helped me learn about it (and address sanitizers!) and even file a huntr.dev report on one of the packages I maintain :)

[Joshua Peisach (itzswirlz)]

No dice.

I can still run gthumb, and in the file loader (main menu), but clicking on it to the main image viewer still causes segfault.

==42869== Invalid read of size 8
==42869== at 0x1796EE: gth_viewer_page_file_loaded_cb (gth-browser.c:6255)
==42869== by 0x179B37: _gth_browser_load_file (gth-browser.c:6340)
==42869== by 0x179C6E: load_file_delayed_cb (gth-browser.c:6378)
==42869== by 0x4A06BE7: g_timeout_dispatch (gmain.c:4800)
==42869== by 0x4A0604D: g_main_dispatch (gmain.c:3309)
==42869== by 0x4A0604D: g_main_context_dispatch (gmain.c:3974)
==42869== by 0x4A063FF: g_main_context_iterate.isra.0 (gmain.c:4047)
==42869== by 0x4A064A2: g_main_context_iteration (gmain.c:4108)
==42869== by 0x4BC5FE4: g_application_run (gapplication.c:2559)
==42869== by 0x1FA860: main (main.c:55)
==42869== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==42869==
==42869==
==42869== Process terminating with default action of signal 11 (SIGSEGV)
==42869== Access not within mapped region at address 0x0
==42869== at 0x1796EE: gth_viewer_page_file_loaded_cb (gth-browser.c:6255)
==42869== by 0x179B37: _gth_browser_load_file (gth-browser.c:6340)
==42869== by 0x179C6E: load_file_delayed_cb (gth-browser.c:6378)
==42869== by 0x4A06BE7: g_timeout_dispatch (gmain.c:4800)
==42869== by 0x4A0604D: g_main_dispatch (gmain.c:3309)
==42869== by 0x4A0604D: g_main_context_dispatch (gmain.c:3974)
==42869== by 0x4A063FF: g_main_context_iterate.isra.0 (gmain.c:4047)
==42869== by 0x4A064A2: g_main_context_iteration (gmain.c:4108)
==42869== by 0x4BC5FE4: g_application_run (gapplication.c:2559)
==42869== by 0x1FA860: main (main.c:55)
==42869== If you believe this happened as a result of a stack
==42869== overflow in your program's main thread (unlikely but
==42869== possible), you can try to increase the size of the
==42869== main thread stack using the --main-stacksize= flag.
==42869== The main thread stack size used in this run was 8388608.

I got rid of a data unref, and that lead to a conditional jump.

I am super confused... you sure you applied *all* three patches?

https://gitlab.gnome.org/GNOME/gthumb/-/commit/ea9415a703097f805ba227fedda908dfe72c4e90.diff
https://gitlab.gnome.org/GNOME/gthumb/-/commit/9729b8688d5d67c01deabea46ad469ec517250c5.diff
https://gitlab.gnome.org/GNOME/gthumb/-/commit/14860321ce3235d420498c4f81f21003d1fb78f4.diff

[Fabian Toepfer (fabiantoepfer)]

Hey Joshua, no problem, thanks for your feedback! I'm not using this tool right now, but I'll definitely check it out! I'm happy to read you enjoy learning about all these things same as I do :)

Thank you for sharing the trace, are you getting into this error directly when starting the app or are you loading a file or one of the PoCs? I think I got the same error today directly at startup when I executed the binary from the build directory, but after running the install step, I no longer got the problem. I couldn't trigger the problem again afterwards, so I assume it was about some inconsistencies in the environment.

Let me share how I build the program from source for testing:

meson build -Db_sanitize=address,undefined -Dbuildtype=release -Dprefix=/usr
cd build
ninja
ninja install

Maybe you can try to clean your env, remove gthumb and gthumb-data and then do the same and check if the problem still occurs for you?

Today I also noticed that the image 20200704_174327.jpg still causes an overflow that goes unnoticed without sanitizer enabled, so I'll share it right now in case you also encounter this problem:

==79994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000a010d3 at pc 0x7f71c3158490 bp 0x7f71875f3a20 sp 0x7f71875f31c8
READ of size 5 at 0x602000a010d3 thread T30 (pool-gthumb)
    #0 0x7f71c315848f in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
    #1 0x7f71c2ec9fd0 in g_utf8_substring (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x84fd0)
    #2 0x55d04920bf73 in _g_utf8_has_prefix (/usr/bin/gthumb+0x5c3f73)
    #3 0x7f719f311621 in create_metadata(char const*, char const*, char const*, char const*, char const*, char const*) (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0x84621)
    #4 0x7f719f31c29d in exiv2_read_metadata(std::auto_ptr<Exiv2::Image>, _GFileInfo*, int) (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0x8f29d)
    #5 0x7f719f3310b6 in exiv2_read_metadata_from_file (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0xa40b6)
    #6 0x7f719f34ebcc in gth_metadata_provider_exiv2_read (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0xc1bcc)
    #7 0x55d04948615e in _g_query_metadata_async_thread (/usr/bin/gthumb+0x83e15e)
    #8 0x7f71c2d13c61 (/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xb5c61)
    #9 0x7f71c2ec1373 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7c373)
    #10 0x7f71c2ec0ad0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7bad0)
    #11 0x7f71c1497608 in start_thread /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477
    #12 0x7f71c13bc132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)

I did another bisect and found these two (unfortunately huge!) commits 62b059b5591baba80b46b17f1042a5065b43deaa, 7cad30b55c8c17fa03508c1f32db613fc9e2b198 after which the problem no longer occurs.
I tried to take the stack as reference and replaced the function _g_utf8_has_prefix with the updated one from 62b059b5591baba80b46b17f1042a5065b43deaa and it seems to solve the problem.

Hope we get this done together :)

[Joshua Peisach (itzswirlz)]

I get the error when I load in the POCs, specifically clicking on the iamge.

Maybe it was an environment thing? I guess I can try again. But if these patches are huge is it even worth patching or just leave it in a crashed state that doesn't trigger a buffer overflow? Considering flavor support for 20.04 ends soon, it might not a bad idea.

[Fabian Toepfer (fabiantoepfer)]

Hm, this should not happen anymore, as I wrote some time ago, the PoCs no longer cause crashes for me with the patches applied, also no graphical glitches.

For the last overflow when loading 20200704_174327.jpg, I think I was correct. The function _g_utf8_has_prefix contains an overflow when the source string is shorter than the prefix string, then g_utf8_substring is called on the source string with length of the prefix string. So I only patched the function _g_utf8_has_prefix as it was done in the huge commit.

I've attached my current debdiff, maybe you can have a look and try again please?

[Fabian Toepfer (fabiantoepfer)]

Hey Joshua, did you find time to try out my proposed debdiff?

[Joshua Peisach (itzswirlz)]

PHEW - It works! Sorry!! I've been backlogged with school!

I'll put ensuring dch and all is up to date on my TODO list - but IMO you should be credited for the patch

[Fabian Toepfer (fabiantoepfer)]

Thank's for confirming! No worries, this is fine, I'll take care of the rest. Thank you for your contribution!

[Launchpad Janitor (janitor)]

This bug was fixed in the package gthumb - 3:3.8.0-2.1ubuntu0.1

---------------
gthumb (3:3.8.0-2.1ubuntu0.1) focal-security; urgency=medium

  * SECURITY UPDATE: Heap buffer overflow
    - debian/patches/CVE-2019-20326-*.patch: Do not scan
      more than CAIRO_MAX_IMAGE_SIZE lines. (LP: #1976189)
    - CVE-2019-20326
  * SECURITY UPDATE: Heap buffer overflow
    - debian/patches/CVE-2020-36427-*.patch: Fixed crash in
      case of some malformed jpegs. (LP: #1976189)
    - CVE-2020-36427

 -- Fabian Toepfer <email address hidden> Sun, 29 May 2022 12:31:15 -0400