The ImageMagick Engine ImageMagick Engine WordPress plugin before 1.7.11 for WordPress is vulnerable to OS Command Injection via the "clipath" parameter. This allows authenticated attackers, with administrator-level permission to execute arbitrary OS commands on the server leading to remote code execution.

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

A heap use-after-free flaw was found in coders/bmp.c in ImageMagick.

An issue was discovered with ImageMagick 7.1.0-4 via Division by zero in function ReadEnhMetaFile of coders/emf.c.

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.

A memory leak in ImageMagick 7.0.10-45 and 6.9.11-22 allows remote attackers to perform a denial of service via the "identify -help" command.

ImageMagick before 6.9.12-91 allows attackers to cause a denial of service (memory consumption) in Magick::Draw.

A heap-based buffer overflow issue was found in ImageMagick's PushCharPixel() function in quantum-private.h. This issue may allow a local attacker to trick the user into opening a specially crafted file, triggering an out-of-bounds read error and allowing an application to crash, resulting in a denial of service.

A heap-based buffer overflow vulnerability was found in coders/tiff.c in ImageMagick. This issue may allow a local attacker to trick the user into opening a specially crafted file, resulting in an application crash and denial of service.

A heap-based buffer overflow issue was discovered in ImageMagick's ReadTIM2ImageData() function in coders/tim2.c. A local attacker could trick the user in opening specially crafted file, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.

A heap use after free issue was discovered in ImageMagick's ReplaceXmpValue() function in MagickCore/profile.c. An attacker could pass specially crafted file to convert, triggering an heap-use-after-free write error, allowing an application to crash, resulting in a denial of service.

https://github.com/ImageMagick/ImageMagick/commit/1061db7f80fdc9ef572ac60b55f408f7bab6e1b0

A stack-based buffer overflow issue was found in ImageMagick's coders/tiff.c. This flaw allows an attacker to trick the user into opening a specially crafted malicious tiff file, causing an application to crash, resulting in a denial of service.

Hi,

Reading changelog and code of imagemagick, I want to report a stack overflow with crafted tiff file in imagemagick

Fixed (after 6.9.12-26) by: https://github.com/ImageMagick/ImageMagick6/commit/85a370c79afeb45a97842b0959366af5236e9023

Original reporter was Muhammad Aldo Firmansyah

Thanks

Bastien (rouca)

Shell command injection vulnerability via video:vsync or video:pixel-format options in VIDEO encoding/decoding https://github.com/ImageMagick/ImageMagick/issues/6338

Undefined behaviors of casting double to sizet in svg, mvg and other coders (recurring bugs of CVE-2022-32546) https://github.com/ImageMagick/ImageMagick/issues/6341

A Heap Buffer Overflow issue in imagemagick, which has been fixed here: https://github.com/ImageMagick/ImageMagick/commit/9a9896fce95d09e5e47b86baccbe1ce1a2fca76b

A heap-based buffer overflow issue was discovered in ImageMagick's ImportMultiSpectralQuantum() function in MagickCore/quantum-import.c. An attacker could pass specially crafted file to convert, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.

ImageMagick 7.1.0-49 is vulnerable to Information Disclosure. When it parses a PNG image (e.g., for resize), the resulting image could have embedded the content of an arbitrary. file (if the magick binary has permissions to read it).

ImageMagick 7.1.0-49 is vulnerable to Denial of Service. When it parses a PNG image (e.g., for resize), the convert process could be left waiting for stdin input.

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

A heap buffer overflow issue was found in ImageMagick. When an application processes a malformed TIFF file, it could lead to undefined behavior or a crash causing a denial of service.

A vulnerability was found in ImageMagick-7.0.11-5, where executing a crafted file with the convert command, ASAN detects memory leaks.

An integer overflow issue was discovered in ImageMagick's ExportIndexQuantum() function in MagickCore/quantum-export.c. Function calls to GetPixelIndex() could result in values outside the range of representable for the 'unsigned char'. When ImageMagick processes a crafted pdf file, this could lead to an undefined behaviour or a crash.

In ImageMagick 7.1.0-29, a crafted file could trigger an assertion failure when a call to WriteImages was made in MagickWand/operation.c, due to a NULL image list. This could potentially cause a denial of service. This was fixed in upstream ImageMagick version 7.1.0-30.

References: https://github.com/ImageMagick/ImageMagick/commit/716496e6df0add89e9679d6da9c0afca814cfe49

It was discovered that ImageMagick incorrectly handled certain values. If a user were tricked into processing a specially crafted image file, an attacker could possibly exploit this issue to cause a denial of service or other unspecified impact. (CVE-2022-32545, CVE-2022-32546) It was discovered that ImageMagick incorrectly handled memory under certain circumstances. If a user were tricked into processing a specially crafted image file, an attacker could possibly exploit this issue to cause a denial of service or other unspecified impact. (CVE-2022-32547)

End of life: 12/21/2022, Latest version: 3.20.0

End of life: 12/21/2022, Latest version: 3.20.0

A vulnerability was found in ImageMagick, causing an outside the range of representable values of type 'unsigned char' at coders/psd.c, when crafted or untrusted input is processed. This leads to a negative impact to application availability or other problems related to undefined behavior.

In ImageMagick version < 7.1.0-30, there are runtime errors:

load of misaligned address 0x62300000714d for type 'double', which requires 8 byte alignment load of misaligned address 0x62300000710b for type 'float', which requires 4 byte alignment

References: https://github.com/ImageMagick/ImageMagick/issues/5033 https://github.com/ImageMagick/ImageMagick/pull/5034

A vulnerability was found in ImageMagick, causing an outside the range of representable values of type 'unsigned long' at coders/pcl.c, when crafted or untrusted input is processed. This leads to a negative impact to application availability or other problems related to undefined behavior.