Malformed input causing huge malloc

[hanno]

The first time I posted this it got deleted and my account locked, but according to twitter replies this happened by accident Therefore I post it again.

I was fuzzing imagemagick's identify command and on certain input files it tries to allocate huge amounts of memory. This would be okay if imagemagick would be configured to unlimited memory, but it also happens if I intentionally limit identify's memory, e.g. with -limit map 32 -limit area 32. Therefore I think this is a bug.

Here's one sample input causing this:
https://crashes.fuzzing-project.org/ima ... alloc-fail

[fmw42]

Your link downloads an unknown named file that is garbage.

[hanno]

That's the point of fuzzing, it's "garbage" that imagemagick will try to interpret and expose bugs on doing so.

Forgot in the initial post, here's the address sanitizer stack trace:

Code: Select all

==9248==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.6.1/work/llvm-3.6.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:124 "(("unable to mmap" && 0)) != (0)" (0x0, 0x0)
    #0 0x4e4074 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/mnt/ram/imagemagick/identify+0x4e4074)
    #1 0x4ea9f1 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/mnt/ram/imagemagick/identify+0x4ea9f1)
    #2 0x4f3163 in __sanitizer::MmapOrDie(unsigned long, char const*) (/mnt/ram/imagemagick/identify+0x4f3163)
    #3 0x459e32 in __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback>::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) (/mnt/ram/imagemagick/identify+0x459e32)
    #4 0x459cdb in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback> >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) (/mnt/ram/imagemagick/identify+0x459cdb)
    #5 0x456f14 in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) (/mnt/ram/imagemagick/identify+0x456f14)
    #6 0x4dc5ac in __interceptor_malloc (/mnt/ram/imagemagick/identify+0x4dc5ac)
    #7 0x541d48 in AcquireMagickMemory /f/ImageMagick-6.9.0-3/magick/memory.c:464:10
    #8 0x541d48 in AcquireQuantumMemory /f/ImageMagick-6.9.0-3/magick/memory.c:540
    #9 0x824fe5 in ReadRLEImage /f/ImageMagick-6.9.0-3/coders/rle.c:265:36
    #10 0xa1fc58 in ReadImage /f/ImageMagick-6.9.0-3/magick/constitute.c:492:13
    #11 0xc50801 in ReadStream /f/ImageMagick-6.9.0-3/magick/stream.c:974:9
    #12 0xa1ea0b in PingImage /f/ImageMagick-6.9.0-3/magick/constitute.c:226:9
    #13 0xa1f169 in PingImages /f/ImageMagick-6.9.0-3/magick/constitute.c:321:10
    #14 0xc7451e in IdentifyImageCommand /f/ImageMagick-6.9.0-3/wand/identify.c:324:18
    #15 0xc96881 in MagickCommandGenesis /f/ImageMagick-6.9.0-3/wand/mogrify.c:168:14
    #16 0x4fb9ee in IdentifyMain /f/ImageMagick-6.9.0-3/utilities/identify.c:80:10
    #17 0x4fb9ee in main /f/ImageMagick-6.9.0-3/utilities/identify.c:93
    #18 0x7f4e305f0f9f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289
    #19 0x455526 in _start (/mnt/ram/imagemagick/identify+0x455526)

[magick]

ImageMagick limits the allocation of pixel in the cache but not all allocations such in this case where the image colormap is the culprit. On our Fedora box, ImageMagick exits gracefully with "memory allocation failed ". ImageMagick does have a general memory allocator that consults the limits but it is not used in all cases. Either way, we have a fix for the problem your reported in ImageMagick 6.1.9-6 Beta, available by sometime tomorrow. Thanks for alerting us to the problem.

[hanno]

Here are three more cases:
https://crashes.fuzzing-project.org/ima ... adBMPImage
https://crashes.fuzzing-project.org/ima ... adPCXImage
https://crashes.fuzzing-project.org/ima ... adRLEImage

Although ImageMagick exists gracefully I think these issues can be abused by an attacker to cause a huge memory allocation that just fits into a systems memory, thereby causing DoS. Therefore I think these should be fixed.

[dlemstra]

For your info, we recently added -limit width and height to limit the dimensions of an image. That could help you in other situations.

[magick]

We're using ImageMagick 6.9.1-6. Each file exits gracefully with these exceptions:

• length and filesize do not match `imagemagick-malloc-fail-ReadBMPImage'
  memory allocation failed `imagemagick-malloc-fail-ReadPCXImage'
  memory allocation failed `imagemagick-malloc-fail-ReadRLEImage'

As Dirk suggests, use limits to help prevent DOS. Here is the policy file we use on our system:

Code: Select all

<policymap>
  <policy domain="resource" name="temporary-path" value="/tmp"/>
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="width" value="8KP"/>
  <policy domain="resource" name="height" value="8KP"/>
  <policy domain="resource" name="map" value="512MiB"/>
  <policy domain="resource" name="area" value="128MB"/>
  <policy domain="resource" name="disk" value="1GiB"/>
  <policy domain="resource" name="file" value="768"/>
  <policy domain="resource" name="thread" value="2"/>
  <policy domain="resource" name="throttle" value="0"/>
  <policy domain="resource" name="time" value="120"/>
  <policy domain="system" name="precision" value="6"/>
  <policy domain="cache" name="shared-secret" value="My voice is my passport.  Verify me."/>
</policymap>

[hanno]

Thanks for the note with the height/width limit.

However given the description of the "area" limit I'd still consider these a bug if these try to alloc huge amounts of memory if a limit is set. Or am I misunderstanding something here?

[magick]

Area limits force the pixel cache from memory to disk. Keep in mind, other sorts of memory allocations may come from the system heap. In some cases the heap request is data driven. Its up to the system to permit or deny the allocation. If its denied, ImageMagick returns an exception.