| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| Magick.NET-Q16-AnyCPU | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-AnyCPU | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-OpenMP-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-OpenMP-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-HDRI-x86 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-OpenMP-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-OpenMP-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q16-x86 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-AnyCPU | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-OpenMP-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-OpenMP-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-arm64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-x64 | < 14.7.0 | 14.7.0 |
| Magick.NET-Q8-x86 | < 14.7.0 | 14.7.0 |
| imagemagick | ≥ 7.0.0-0, < 7.1.2-0< 6.9.13-26 | 7.1.2-06.9.13-26 |
Hi, we have found a stack buffer overflow and would like to report this issue. Could you confirm if this qualifies as a security vulnerability? I am happy to provide any additional information needed.
In ImageMagick's magick mogrify command, specifying multiple consecutive %d format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through vsnprintf().
Upon further investigation, we found that the same issue occurs not only with mogrify but also with the following subcommands: compare, composite, conjure, convert, identify, mogrify, and montage.
Furthermore, we confirmed that this vulnerability has the potential to lead to RCE. RCE is possible when ASLR is disabled and there is a suitable one_gadget in libc, provided that options and filenames can be controlled.
# Clone source
git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1
cd ImageMagick-7.1.1
# Build with ASan
CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install
# Trigger crash
./utilities/magick mogrify %d%d
==4155==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffda834caae at pc 0x7f1ea367fb27 bp 0x7ffda834b680 sp 0x7ffda834ae10
WRITE of size 2 at 0x7ffda834caae thread T0
#0 0x7f1ea367fb26 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668
#1 0x7f1ea2dc9e3e in FormatLocaleStringList MagickCore/locale.c:470
#2 0x7f1ea2dc9fd9 in FormatLocaleString MagickCore/locale.c:495
#3 0x7f1ea2da0ad5 in InterpretImageFilename MagickCore/image.c:1696
#4 0x7f1ea2c6126b in ReadImages MagickCore/constitute.c:1051
#5 0x7f1ea27ef29b in MogrifyImageCommand MagickWand/mogrify.c:3858
#6 0x7f1ea278e95d in MagickCommandGenesis MagickWand/magick-cli.c:177
#7 0x560813499a0c in MagickMain utilities/magick.c:153
#8 0x560813499cba in main utilities/magick.c:184
#9 0x7f1ea1c0bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#10 0x7f1ea1c0be3f in __libc_start_main_impl ../csu/libc-start.c:392
#11 0x560813499404 in _start (/root/workdir/ImageMagick/utilities/.libs/magick+0x2404)
Address 0x7ffda834caae is located in stack of thread T0 at offset 62 in frame
#0 0x7f1ea2c60f62 in ReadImages MagickCore/constitute.c:1027
This frame has 2 object(s):
[32, 40) 'images' (line 1033)
[64, 4160) 'read_filename' (line 1029) <== Memory access at offset 62 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 in __interceptor_vsnprintf
Shadow bytes around the buggy address:
0x100035061900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100035061910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100035061920: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3
0x100035061930: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x100035061940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100035061950: f1 f1 00 f2 f2[f2]00 00 00 00 00 00 00 00 00 00
0x100035061960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100035061970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100035061980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100035061990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000350619a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==4155==ABORTING
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンIn MagickCore/image.c, within the InterpretImageFilename() function:
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
Image *image,const char *format,int value,char *filename,
ExceptionInfo *exception)
{
...
for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
{
q=(char *) p+1;
if (*q == '%')
{
p=q+1;
continue;
}
field_width=0;
if (*q == '0')
field_width=(ssize_t) strtol(q,&q,10);
switch (*q)
{
case 'd':
case 'o':
case 'x':
{
q++;
c=(*q);
*q='\0';
/*--------Affected--------*/
(void) FormatLocaleString(filename+(p-format-offset),(size_t)
(MagickPathExtent-(p-format-offset)),p,value);
offset+=(4-field_width);
/*--------Affected--------*/
*q=c;
(void) ConcatenateMagickString(filename,q,MagickPathExtent);
canonical=MagickTrue;
if (*(q-1) != '%')
break;
p++;
break;
}
case '[':
{
...
}
default:
break;
}
}
This vulnerability is caused by an inconsistency in the template expansion processing within InterpretImageFilename().
The format specifiers %d, %o, and %x in templates are replaced with integer values by FormatLocaleString(), but the output buffer position is calculated by filename + (p - format - offset).
The offset variable is cumulatively incremented to correct the output length of %d etc., but the design using a static offset += (4 - field_width) causes offset to increase excessively when % specifiers are consecutive in the template, creating a dangerous state where the write destination address points before filename.
The constant 4 was likely chosen based on the character count of typical format specifiers like %03d (total of 4 characters: %, 0, 3, d). However, in reality, there are formats with only 2 characters like %d, and formats with longer width specifications (e.g., %010d), so this uniform constant-based correction is inconsistent with actual template structures.
As a result, when the correction value becomes excessive, offset exceeds the relative position p - format within the template, generating a negative index. This static and template-independent design of the correction processing is the root cause of this vulnerability.
This causes vsnprintf() to write outside the stack buffer range, which is detected by AddressSanitizer as a stack-buffer-overflow.
In MagickCore/image.c, within the InterpretImageFilename() function:
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
Image *image,const char *format,int value,char *filename,
ExceptionInfo *exception)
{
...
/*--------Changed--------*/
ssize_t
field_width,
offset,
written; // Added
/*--------Changed--------*/
...
for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
{
q=(char *) p+1;
if (*q == '%')
{
p=q+1;
continue;
}
field_width=0;
if (*q == '0')
field_width=(ssize_t) strtol(q,&q,10);
switch (*q)
{
case 'd':
case 'o':
case 'x':
{
q++;
c=(*q);
*q='\0';
written = FormatLocaleString(filename+(p-format-offset),(size_t)
(MagickPathExtent-(p-format-offset)),p,value);
/*--------Changed--------*/
if (written <= 0 || written > (MagickPathExtent - (p - format - offset)))
return 0;
offset += (ssize_t)((q - p) - written);
/*--------Changed--------*/
*q=c;
(void) ConcatenateMagickString(filename,q,MagickPathExtent);
canonical=MagickTrue;
if (*(q-1) != '%')
break;
p++;
break;
}
case '[':
{
...
}
default:
break;
}
}
offset based on the difference between template description length (q - p) and the number of output bytes written, buffer position consistency is maintained.written allows detection of vsnprintf failures and excessive writes.Fixed in https://github.com/ImageMagick/ImageMagick/commit/66dc8f51c11b0ae1f1cdeacd381c3e9a4de69774 and https://github.com/ImageMagick/ImageMagick6/commit/643deeb60803488373cd4799b24d5786af90972e