GraphicsMagick before 8e56520 has a heap-based buffer over-read in ReadJXLImage in coders/jxl.c, related to an ImportViewPixelArea call.

Last updated 14 April 2025

Last updated 14 April 2025

On Sun, Oct 22, 2023 at 09:19:59AM -0500, Bob Friesenhahn wrote: On Sat, 21 Oct 2023, Demi Marie Obenour wrote: For Rocky Linux Security SIG, the only relevant thing mentioned so far was possibly offering an OpenBSD pledge()-alike that other packages could use. However, I am skeptical any actually would, unless we also introduce such uses ourselves and maintain own "override" packages (replacing RHEL rebuild ones or those coming from EPEL, etc.) of such software. Initially, we are going to only create "override' packages for core or very commonly used/exposed components, and to do so only for specific good reasons. So stuff like e.g. ImageMagick/GraphicsMagick coming from EPEL and with most of its dependency libraries coming from AppStream repos, or e.g. GraphViz coming from AppStream, is unlikely to make the cut, at least not initially. Has deprecating ImageMagick and/or GraphicsMagick outright been considered? I don’t just mean the downstream packages, but the entire upstream projects, or at least the libraries. RHEL already deprecated ImageMagick several years ago and advised users to use GraphicsMagick (https://access.redhat.com/documentation/en-us/redhatenterpriselinux/7/html/7.7releasenotes/deprecatedfunctionality). Those users were confused given that many of the recipes they were using for ImageMagick did not work with GraphicsMagick. The solution for those users was to find a different way to install ImageMagick. One option would be to instead make an IPC call to a persistent daemon running in the background. That said, has wasm2c been considered? The best fix would be something that can make C code memory-safe, even if it comes at a performance hit of 4x or more (like SoftBound+CETS did). Stuff that cares about performance should be migrating to something like libvips or ImageFlow.

If neither of these are options, I think the entire library will need to be deprecated for eventual removal. The command-line tools can remain, but they can be much more strongly sandboxed than a library can, because they have the entire process to themselves. Any deprecations or sandboxing approaches which fail to understand and address the needs of the "user" will fail. Replacing package 'A' with package 'B', where package 'B' works totally differently, or performs different functions than package 'A' will fail because the users will not use it. That is true. Unfortunately, most Linux IPC mechanisms are not very secure since they rely on historical Unix privilege models to control access. If one can bypass access control on IPC, one can easily get root by sending malicious commands to systemd, so I don't think this is something to worry about. Common ways to assure security such as TLS usually result in a considerable reduction of performance. Solutions like Landlock seem useful for very restricted usage applications. Sandboxing solutions which work for any use of a program seem better than requiring a client/server model. The advantage of a client/server model is that it avoids a library having to spawn child processes, which was mentioned as a concern earlier. I agree that it is more effort than desirable. As the developer/maintainer of a complex C program (GraphicsMagick), I appreciate any advice on improvements which make it more suitable for sandboxing, or less likely to appear as a hazard on the security radar. To make a program suitable for sandboxing, several requirements must be met:

1. The program must run in a separate address space. This can either be a OS process, a software fault isolation (SFI) container, or a SFI container inside an OS process. If an SFI container is used without a separate OS process, additional care must be taken to prevent side-channel attacks, so I do not recommend this solution without significant additional research.

2. All I/O resources (such as file descriptors) must be acquired before processing untrusted input. It must not be possible to use these resources to access additional resources the program should not have access to.

3. Before processing untrusted input, the program must lose the ability to acquire additional I/O resources.

4. The address space (whether an OS process or an SFI container) must not be reused once processing has completed, unless it can be forcibly and verifiably reset to its initial state.

5. If the inputs to the processing were untrusted, the results must also be considered untrusted.

A command-line tool can probably meet all of these requirements but the last one quite easily. For a library, the difficulty of meeting these requirements will depend significantly on the library API. I am not familiar with the GraphicsMagick API and so am not sure how difficult it will be for the GraphicsMagick API to support sandboxing. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab

Buffer Overflow vulnerability in WritePCXImage function in pcx.c in GraphicsMagick 1.4 allows remote attackers to cause a denial of service via converting of crafted image file to pcx format.

In GraphicsMagick, a heap buffer overflow was found when parsing MIFF.

GraphicsMagick through 1.3.35 has a heap-based buffer overflow in ReadMNGImage in coders/png.c.

GraphicsMagick before 1.3.35 has an integer overflow and resultant heap-based buffer overflow in HuffmanDecodeImage in magick/compress.c.

In GraphicsMagick before 1.3.32, the text filename component allows remote attackers to read arbitrary files via a crafted image because of TranslateTextEx for SVG.

It was discovered that GraphicsMagick incorrectly handled certain image files. An attacker could possibly use this issue to cause a denial of service or other unspecified impact.

In GraphicsMagick 1.4 snapshot-20190403 Q8, there is a use-after-free in ThrowException and ThrowLoggedException of magick/error.c.

In GraphicsMagick 1.4 snapshot-20190423 Q8, there is a heap-based buffer overflow in the function ImportRLEPixels of coders/miff.c.

In GraphicsMagick 1.4 snapshot-20191208 Q8, there is a heap-based buffer over-read in the function EncodeImage of coders/pict.c.

In GraphicsMagick from version 1.3.30 to 1.4 snapshot-20190403 Q8, there is a heap-based buffer overflow in the function WriteMATLABImage of coders/mat.c, which allows an attacker to cause a denial of service or possibly have unspecified other impact via a crafted image file. This is related to ExportRedQuantumType in magick/export.c.

In GraphicsMagick from version 1.3.8 to 1.4 snapshot-20190403 Q8, there is a heap-based buffer overflow in the function WritePDBImage of coders/pdb.c, which allows an attacker to cause a denial of service or possibly have unspecified other impact via a crafted image file. This is related to MagickBitStreamMSBWrite in magick/bitstream.c.

coders/xwd.c in GraphicsMagick 1.3.31 allows attackers to cause a denial of service (floating-point exception and application crash) by crafting an XWD image file, a different vulnerability than CVE-2019-11008 and CVE-2019-11009.

coders/xwd.c in GraphicsMagick 1.3.31 allows attackers to cause a denial of service (out-of-bounds read and application crash) by crafting an XWD image file, a different vulnerability than CVE-2019-11008 and CVE-2019-11009.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a memory leak in the function ReadMPCImage of coders/mpc.c, which allows attackers to cause a denial of service via a crafted image file.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a heap-based buffer over-read in the function ReadXWDImage of coders/xwd.c, which allows attackers to cause a denial of service or information disclosure via a crafted image file.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a heap-based buffer overflow in the function WriteXWDImage of coders/xwd.c, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted image file.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a heap-based buffer over-read in the ReadMNGImage function of coders/png.c, which allows attackers to cause a denial of service or information disclosure via an image colormap.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a heap-based buffer over-read in the function ReadMIFFImage of coders/miff.c, which allows attackers to cause a denial of service or information disclosure via an RLE packet.

In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a stack-based buffer overflow in the function SVGStartElement of coders/svg.c, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a quoted font family value.

ImageMagick is vulnerable to a denial of service, caused by memory leaks in WritePDFImage in coders/pdf.c. By persuading a victim to open a specially-crafted file, a remote attacker could exploit this vulnerability to cause the application to crash.

In GraphicsMagick 1.3.31, the ReadDIBImage function of coders/dib.c has a vulnerability allowing a crash and denial of service via a dib file that is crafted to appear with direct pixel values and also colormapping (which is not available beyond 8-bits/sample), and therefore lacks indexes initialization.

In GraphicsMagick 1.4 snapshot-20181209 Q8, there is a heap-based buffer overflow in the WriteTGAImage function of tga.c, which allows attackers to cause a denial of service via a crafted image file, because the number of rows or columns can exceed the pixel-dimension restrictions of the TGA specification.

In GraphicsMagick 1.4 snapshot-20181209 Q8 on 32-bit platforms, there is a heap-based buffer over-read in the ReadBMPImage function of bmp.c, which allows attackers to cause a denial of service via a crafted bmp image file. This only affects GraphicsMagick installations with customized BMP limits.

A flaw was found in ImageMagick 7.0.8-13 Q16. A memory leak in the function WriteMSLImage of coders/msl.c.

References: https://github.com/ImageMagick/ImageMagick/issues/1360

Upstream Patch: https://github.com/ImageMagick/ImageMagick/commit/c9c4ef4e7ca83d8a00effd16723f37946e89fbad

In GraphicsMagick 1.3.28, there is a divide-by-zero in the ReadMNGImage function of coders/png.c. Remote attackers could leverage this vulnerability to cause a crash and denial of service via a crafted mng file.

An issue was discovered in GraphicsMagick 1.3.26. An allocation failure vulnerability was found in the function ReadTIFFImage in coders/tiff.c, which allows attackers to cause a denial of service via a crafted file, because file size is not properly used to restrict scanline, strip, and tile allocations.