{"id":124102,"date":"2021-06-30T08:00:42","date_gmt":"2021-06-30T15:00:42","guid":{"rendered":"\/blogs\/?p=124102"},"modified":"2024-07-08T01:10:19","modified_gmt":"2024-07-08T08:10:19","slug":"fuzzing-imagemagick-and-digging-deeper-into-cve-2020-27829","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/fuzzing-imagemagick-and-digging-deeper-into-cve-2020-27829\/","title":{"rendered":"Fuzzing ImageMagick and Digging Deeper into CVE-2020-27829"},"content":{"rendered":"

Introduction:<\/strong><\/h2>\n

ImageMagick is a hugely popular open source software that is used in lot of systems around the world. It is available for the Windows, Linux, MacOS platforms as well as Android and iOS. It is used for editing, creating or converting various digital image formats and supports various formats like PNG, JPEG, WEBP, TIFF, HEIC and PDF, among others.<\/p>\n

Google OSS Fuzz and other threat researchers have made ImageMagick the frequent focus of fuzzing, an extremely popular technique used by security researchers to discover potential zero-day vulnerabilities in open, as well as closed source software. This research has resulted in various vulnerability discoveries that must be addressed on a regular basis by its maintainers. Despite the efforts of many to expose such vulnerabilities, recent fuzzing research from McAfee has exposed new vulnerabilities involving processing of multiple image formats, in various open source and closed source software and libraries including ImageMagick and Windows GDI+.<\/p>\n

Fuzzing ImageMagick:<\/strong><\/h3>\n

Fuzzing open source libraries has been covered in a detailed blog \u201cVulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade\u201d<\/a> last year. Fuzzing ImageMagick is very well documented, so we will be quickly covering the process in this blog post and will focus on the root cause analysis of the issue we have found.<\/p>\n

Compiling ImageMagick with AFL:<\/strong><\/h3>\n

ImageMagick has lot of configuration options which we can see by running following command:<\/p>\n\n\n\n
$.\/configure \u2013help<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

We can customize various parameters as per our needs. To compile and install ImageMagick with AFL for our case, we can use following commands:<\/p>\n\n\n\n
$CC=afl-gcc CXX=afl=g++ CFLAGS=”-ggdb -O0 -fsanitize=address,undefined -fno-omit-frame-pointer” LDFLAGS=”-ggdb -fsanitize=address,undefined -fno-omit-frame-pointer” .\/configure<\/strong><\/p>\n

$<\/strong> make -j$(nproc)<\/strong><\/p>\n

$sudo make install<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This will compile and install ImageMagick with AFL instrumentation. The binary we will be fuzzing is \u201cmagick<\/strong>\u201d, also known as \u201cmagick tool\u201d. It has various options, but we will be using its image conversion feature to convert our image from one format to another.<\/p>\n

A simple command would be include the following:<\/p>\n\n\n\n
$ magick <input file> <output file><\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This command will convert an input file to an output file format. We will be fuzzing this with AFL.<\/p>\n

Collecting Corpus:<\/strong><\/h3>\n

Before we start fuzzing, we need to have a good input corpus. One way of collecting corpus is to search on Google or GitHub. We can also use existing test corpus from various software. A good test corpus is available on the \u00a0AFL site here: https:\/\/lcamtuf.coredump.cx\/afl\/demo\/<\/a><\/p>\n

Minimizing Corpus:<\/strong><\/h3>\n

Corpus collection is one thing, but we also need to minimize the corpus. The way AFL works is that it will instrument each basic block so that it can trace the program execution path. It maintains a shared memory as a bitmap and it uses an algorithm to check new block hits. If a new block hit has been found, it will save this information to bitmap.<\/p>\n

Now it may be possible that more than one input file from the corpus can trigger the same path, as we have collected sample files from various sources, we don\u2019t have any information on what paths they will trigger at the runtime. If we use this corpus without removing such files, then we end up wasting time and CPU cycles. We need to avoid that.<\/p>\n

Interestingly AFL offers a utility called \u201cafl-cmin<\/strong>\u201d which we can use to minimize our test corpus. This is a recommended thing to do before you start any fuzzing campaign. We can run this as follows:<\/p>\n\n\n\n
$afl-cmin -i <input directory> -o <output directory> — magick @@ \/dev\/null<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This command will minimize the input corpus and will keep only those files which trigger unique paths.<\/p>\n

Running Fuzzers:<\/strong><\/h3>\n

After we have minimized corpus, we can start fuzzing. To fuzz we need to use following command:<\/p>\n\n\n\n
$afl-fuzz -i <mincorpus directory> -o <output directory> — magick @@ \/dev\/null<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This will only run a single instance of AFL utilizing a single core. In case we have multicore processors, we can run multiple instances of AFL, with one Master and n number of Slaves. Where n is the available CPU cores.<\/p>\n

To check available CPU cores, we can use this command:<\/p>\n\n\n\n
$nproc<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This will give us the number of CPU cores (depending on the system) as follows:<\/p>\n

In this case there are eight cores. So, we can run one Master and up to seven Slaves.<\/p>\n

To run master instances, we can use following command:<\/p>\n\n\n\n
$afl-fuzz -M Master -i <mincorpus directory> -o <output directory> — magick @@ \/dev\/null<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

We can run slave instances using following command:<\/p>\n\n\n\n
$afl-fuzz -S Slave1 -i <mincorpus directory> -o <output directory> — magick @@ \/dev\/null<\/strong><\/p>\n

$afl-fuzz -S Slave2 -i <mincorpus directory> -o <output directory> — magick @@ \/dev\/null<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The same can be done for each slave. We just need to use an argument -S and can use any name like slave1, slave2, etc.<\/p>\n

Results:<\/strong><\/h3>\n

Within a few hours of beginning this Fuzzing campaign, we found one crash related to an out of bound read inside a heap memory. We have reported this issue to ImageMagick, and they were very prompt in fixing it with a patch the very next day. ImageMagick has release a new build with version: 7.0.46 to fix this issue. This issue was assigned CVE-2020-27829<\/strong>.<\/p>\n

Analyzing CVE-2020-27829:<\/strong><\/h3>\n

On checking the POC file, we found that it was a TIFF file.<\/p>\n

When we open this file with ImageMagick with following command:<\/p>\n\n\n\n
$magick poc.tif \/dev\/null<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

As a result, we see a crash like below:<\/p>\n

As is clear from the above log, the program was trying to read 1 byte past allocated heap buffer and therefore ASAN caused this crash. This can atleast lead to a \u00a0ImageMagick crash<\/em> on the systems running vulnerable version of ImageMagick.<\/p>\n

Understanding TIFF file format:<\/strong><\/h3>\n

Before we start debugging this issue to find a root cause, it is necessary to understand the TIFF file format. Its specification is very well described here: http:\/\/paulbourke.net\/dataformats\/tiff\/tiff_summary.pdf<\/a>.<\/p>\n

In short, a TIFF file has three parts:<\/p>\n

    \n
  1. Image File Header (IFH)<\/strong> \u2013 Contains information such as file identifier, version, offset of IFD.<\/li>\n
  2. Image File Directory (IFD)<\/strong> \u2013 Contains information on the height, width, and depth of the image, the number of colour planes, etc. It also contains various TAGs like colormap<\/strong>, page number<\/strong>, BitPerSample<\/strong>, FillOrder,<\/strong><\/li>\n
  3. Bitmap data<\/strong> \u2013 Contains various image data like strips, tiles, etc.<\/li>\n<\/ol>\n

    We can tiffinfo<\/strong> utility from libtiff<\/strong> to gather various information about the POC file. This allows us to see the following information with tiffinfo<\/strong> like width<\/strong>, height<\/strong>, sample per pixel<\/strong>, row per strip<\/strong> etc.:<\/p>\n

    There are a few things to note here:<\/p>\n\n\n\n
    TIFF Dir offset is: 0xa0<\/strong><\/p>\n

    Image width is: 3<\/strong> and length is: 32<\/strong><\/p>\n

    Bits per sample is: 9<\/strong><\/p>\n

    Sample per pixel is: 3<\/strong><\/p>\n

    Rows per strip is: 1024<\/strong><\/p>\n

    Planer configuration is: single image plane<\/strong>.<\/p>\n

    We will be using this data moving forward in this post.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Debugging the issue:<\/strong><\/h3>\n

    As we can see in the crash log, program was crashing at function \u201cPushQuantumPixel\u201d in the following location in quantum-import.c line 256:<\/p>\n

     <\/p>\n

    On checking \u201cPushQuantumPixel\u201d function in \u201cMagickCore\/quantum-import.c\u201d we can see the following code at line #256 where program is crashing:<\/p>\n

    We can see following:<\/p>\n