libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, applications that define unusual custom libvips sources and use them to process untrusted uncompressed PPM images can trigger a max/min error in vipssourcereadtomemory in libvips/iofuncs/source.c. The function uses VIPSMAX instead of VIPSMIN when selecting the remaining read size, allowing up to 4032 bytes to be written beyond the allocated heap buffer and causing memory corruption or a process crash. This issue is fixed in version 8.18.3.

libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, the old-style Radiance RLE decoder in libvips/foreign/radiance.c can process a repeat marker at the beginning of a scanline in scanlinereadold and read q[-1] before any prior pixel exists. A crafted Radiance image loaded through VipsForeignLoadRad can therefore disclose four bytes of adjacent heap data, most likely other image data. This issue is fixed in version 8.18.3.

libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, libvips built without libtiff support but with ImageMagick support can overflow the combined frame height while loading a crafted multi-page TIFF through VipsForeignLoadMagick. The vulnerable calculations in libvips/foreign/magick6load.c and libvips/foreign/magick7load.c multiply the per-page Ysize by nframes without a checked bound, which can cause a heap buffer over-read and process crash. Most package-manager builds include libtiff and do not use this affected fallback path. This issue is fixed in version 8.18.3.

libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, libvips built with libultrahdr support can incorrectly size an output buffer in libvips/foreign/uhdrsave.c within vipsforeignsaveuhdrsetrawhdr when a pipeline enlarges an incoming JPEG to a very large output before encoding a gain map through VipsForeignSaveUhdr. The undersized allocation can cause a heap buffer over-read that may disclose adjacent data or crash the process. This issue is fixed in version 8.18.3.

libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, a crafted many-band TIFF processed through VipsForeignLoadTiff can evade scanline validation in libvips/iofuncs/image.c and cause an integer overflow in vipsimagesanity. The resulting buffer-region calculation can access attacker-controlled negative offsets in mmap-resident allocations, allowing reads or writes of other image data, possible data disclosure through uncompressed .v output, and likely process crashes. Remote code execution has not been demonstrated but cannot be ruled out. This issue is fixed in version 8.18.3.

libvips is a fast image processing library with low memory needs. The tiffload operation in libvips versions before and including 8.18.1 could incorrectly determine the number of channels in a JPEG or JPEG2000-encoded tile within a TIFF image, leading to a possible buffer overflow. This has been patched in version 8.18.2.

libvips is a fast image processing library with low memory needs. The EXIF decoder within libvips versions before and including 8.18.1 was not verifying the range of EXIF tag groups before passing data to libexif, leading to a possible null pointer dereference and crash. This has been patched in version 8.18.2.

libvips is a fast image processing library with low memory needs. On 32-bit systems in versions before and including 8.18.0, the gifload operation could incorrectly determine dimensions leading to an integer overflow. This has been patched in version 8.18.1.

libvips is a fast image processing library with low memory needs. The vipsload operation in versions before and including 8.18.0 could incorrectly determine image dimensions leading to an integer overflow and a subsequent heap-based buffer overflow. This has been patched in version 8.18.1.

A security vulnerability has been detected in libvips up to 8.18.2. The affected element is the function imminposvec of the file libvips/deprecated/vips7compat.c of the component nip2 Handler. Such manipulation of the argument n leads to heap-based buffer overflow. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. The vendor confirms that they will "be removing the deprecated area in libvips 8.19".

A vulnerability was found in libvips 8.19.0. Impacted is the function vipsextractareabuild of the file libvips/conversion/extract.c. The manipulation of the argument extractarea results in integer overflow. The attack requires a local approach. The exploit has been made public and could be used. The patch is identified as 24795bb3d19d84f7b6f5ed86451ad556c8f2fe70. It is advisable to implement a patch to correct this issue.

A vulnerability has been found in libvips 8.19.0. This issue affects the function vipsextractbandbuild of the file libvips/conversion/extract.c. The manipulation of the argument extractband leads to out-of-bounds read. The attack needs to be performed locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 24795bb3d19d84f7b6f5ed86451ad556c8f2fe70. To fix this issue, it is recommended to deploy a patch.

A flaw has been found in libvips 8.19.0. This vulnerability affects the function vipsunpremultiplybuild of the file libvips/conversion/unpremultiply.c. Executing a manipulation of the argument alphaband can lead to out-of-bounds read. The attack needs to be launched locally. The exploit has been published and may be used. This patch is called 7215ead1e0cd7d3703cc4f5fca06d7d0f4c22b91. A patch should be applied to remediate this issue.

A vulnerability was detected in libvips 8.19.0. This affects the function vipsbandrankbuild of the file libvips/conversion/bandrank.c. Performing a manipulation of the argument index results in heap-based buffer overflow. The attack must be initiated from a local position. The exploit is now public and may be used. The patch is named fd28c5463697712cb0ab116a2c55e4f4d92c4088. It is suggested to install a patch to address this issue.

A vulnerability was found in libvips up to 8.18.0. This affects the function vipsforeignloadcsvbuild of the file libvips/foreign/csvload.c. The manipulation results in heap-based buffer overflow. The attack requires a local approach. The exploit has been made public and could be used. The patch is identified as b3ab458a25e0e261cbd1788474bbc763f7435780. It is advisable to implement a patch to correct this issue.

A vulnerability has been found in libvips up to 8.18.0. The impacted element is the function vipsforeignloadmatrixheader of the file libvips/foreign/matrixload.c. The manipulation leads to null pointer dereference. The attack needs to be performed locally. The identifier of the patch is d4ce337c76bff1b278d7085c3c4f4725e3aa6ece. To fix this issue, it is recommended to deploy a patch.

A flaw has been found in libvips up to 8.18.0. The affected element is the function vipsforeignloadmatrixfileisa/vipsforeignloadmatrixheader of the file libvips/foreign/matrixload.c. Executing a manipulation can lead to memory corruption. The attack needs to be launched locally. This patch is called d4ce337c76bff1b278d7085c3c4f4725e3aa6ece. A patch should be applied to remediate this issue.

A vulnerability was determined in libvips up to 8.19.0. The affected element is the function vipssourcereadtomemory of the file libvips/iofuncs/source.c. This manipulation causes heap-based buffer overflow. It is possible to launch the attack on the local host. The attack's complexity is rated as high. The exploitability is described as difficult. The exploit has been publicly disclosed and may be utilized. Patch name: a56feecbe9ed66521d9647ec9fbcd2546eccd7ee. Applying a patch is the recommended action to fix this issue. The confirmation of the bugfix mentions: "[T]he impact of this is negligible, since this only affects custom seekable sources larger than 4 GiB (and the crash occurs in user code rather than libvips itself)."

libvips is a demand-driven, horizontally threaded image processing library. For versions 8.17.1 and below, when libvips is compiled with support for PDF input via poppler, the pdfload operation is affected by a buffer read overflow when parsing the header of a crafted PDF with a page that defines a width but not a height. Those using libvips compiled without support for PDF input are unaffected as well as thosewith support for PDF input via PDFium. This issue is fixed in version 8.17.2. A workaround for those affected is to block the VipsForeignLoadPdf operation via vipsoperationblockset, which is available in most language bindings, or to set VIPSBLOCKUNTRUSTED environment variable at runtime, which will block all untrusted loaders including PDF input via poppler.

libvips is a demand-driven, horizontally threaded image processing library. The heifsave operation could incorrectly determine the presence of an alpha channel in an input when it was not possible to determine the colour interpretation, known internally within libvips as "multiband". There aren't many ways to create a "multiband" input, but it is possible with a well-crafted TIFF image. If a "multiband" TIFF input image had 4 channels and HEIF-based output was requested, this led to libvips creating a 3 channel HEIF image without an alpha channel but then attempting to write 4 channels of data. This caused a heap buffer overflow, which could crash the process. This vulnerability is fixed in 8.16.1.

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

libvips is a demand-driven, horizontally threaded image processing library. A specially crafted SVG input can cause libvips versions 8.14.3 or earlier to segfault when attempting to parse a malformed UTF-8 character. Users should upgrade to libvips version 8.14.4 (or later) when processing untrusted input.

Division-By-Zero vulnerability in Libvips 8.10.5 in the function vipseyepoint, eye.c#L83, and function vipsmaskpoint, mask.c#L85.

imvips2dz in /libvips/libvips/deprecated/imvips2dz.c in libvips before 8.8.2 has an uninitialized variable which may cause the leakage of remote server path or stack address.

vipsforeignloadgifscanimage in foreign/gifload.c in libvips before 8.8.2 tries to access a color map before a DGifGetImageDesc call, leading to a use-after-free.

libvips before 8.7.4 generates output images from uninitialized memory locations when processing corrupted input image data because iofuncs/memory.c does not zero out allocated memory. This can result in leaking raw process memory contents through the output image.

In libvips before 8.6.3, a NULL function pointer dereference vulnerability was found in the vipsregiongenerate function in region.c, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted image file. This occurs because of a race condition involving a failed delayed load and other worker threads.