Yet another memory leak in ImageMagick or how to exploit CVE-2018–16323.
UPD: The author of CVE-2018-16323 is d4d. He contacted us, and he also presented his own PoC at ZeroNights 2018 conference. Video from conference will be available later.
Hi, in this article we’ll talk about ImageMagick vulnerabilities.
TL;DR:
PoC generator for CVE-2018–16323 (Memory leakage via XBM images in ImageMagick)
What is ImageMagick? From imagemagick.org:
Use ImageMagick® to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 200) including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG. Use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.
This is a very rich library for processing images. If you google “how to resize a picture in php” or “how to crop an image”, then most likely you will find advice on how to use ImageMagick. This library has long had security problems. And today we will look at a fresh vulnerability and recall some old ones.
Part 1 — Yet another memory leak
For the past two years vulnerabilities in ImageMagick libraries have been appearing almost every month. Fortunately, many of them are some kind of not applicable DoS, which does not pose serious security problems. But recently we have noticed an interesting CVE-2018–16323.
Sounds easy! But we didn’t find any information about exploit for this vulnerability.
Look at the commit referenced to the CVE:
“XBM coder leaves the hex image data uninitialized if hex value of the pixel is negative“
Hmm.. Let’s explore the XBM file format. A common XBM image looks like this:
Which is very similar to C code. This format is very old and was used in X Window System to store cursor and icon bitmaps used in the X GUI. Each value in keyboard16_bits array represents 8 pixels, each pixel is a single bit and encodes one of two colors — black or white. So there are no negative pixels as one pixel has only two possible values. Hereinafter we will call that array as XBM body array.
Let’s look closer at the ImageMagick code and find out what a “pixel is negative” means at commit details. We need a ReadXBMImage() function. This function reads an image and prepares data for image processing. Seems like variable image contains the image data being processed (Line 225).
Next, at lines 344–348 there is a memory allocation and pointer data now points to the allocated memory start address. Also pointer p points to the same address.
Next 352–360 and 365–371, same code but for different versions of XBM image. As can be seen from the commit both branches are equally vulnerable, so we will consider just one of them. XBM body array reading occurs in the function XBMInteger() which returns an int to variable c . Further at line 358 the value stored in variable c is put to variable by p pointer, then the pointer is incremented.
In the commit we see that in the previous version variable c was checked for negative value, and if it was negative then the loop ended with a break, and that’s why memory leak appeared. If the first value of XBM body array is negative then all allocated memory remains uninitialized and may contain sensitive data from memory, which will be further processed and a new image will be generated from this data. In patched version it was changed, now if value of XBM body array is negative then ImageMagick throws an error.
Now let’s take a closer look at the XBMInteger() function. It takes a pointer image and pointer hex_digits as arguments. The latter is an array which is initilized at line 305. This function maps allowed values to hex values in XBM body array. XBMInteger() reads next byte defined in XBM body array and puts it to unsigned int variable value. There is an interesting moment, this function reads hex-symbols until the stop token appears. This means that we can specify hex values of arbitrary length and so instead of the expected range between 0–255 values for char we can set any unsigned int value which will be stored in variable value. And next fatal fact is that variable value converted to signed int… Bingo!
So we just need to set a value to XBM body array which will be converted to negative int. It is any value above 2,147,483,647 or 0x80000000 in hex. That’s the whole PoC:
#define test_width 500
#define test_height 500
static char test_bits[] = {
0x80000001, };
The amount of leaked memory depends on how you set the height and width parameters. If you set 500x500, therefore, 31250 (500*500/8) bytes will leak! But it depends on how application uses ImageMagick, it may be that it cuts the image to a certain height and width.
While we were testing this PoC, we encountered a problem. Not all the ImageMagick versions below 7.0.8–9 appeared to be vulnerable as described at cvedetails. We found another commit that fixed another vulnerability — CVE-2017–14175 which is a DoS vulnerability for XBM Images processing. And as you can see, it was this particular commit that brought the vulnerability into the code.
Okay let’s try the PoC. Let’s install one of the vulnerable versions (e.g. 6.9.9–51). Now, running convert poc.xbm poc.png we will call processing XBM images in xbm.c file. And therefore call vulnerable code.
The resulting image should be like this:
You can see some noise on the resulting image, this is a leaked memory, each black or white pixel is a bit of information from leaked memory. If you repeat convert, then you will likely get another image, because another memory chunk will be caught.
What do we need to extract leaked memory bytes?
Simply convert it back, convert poc.png leak.xbm, now we see leaked memory bytes in XBM body array and this is very easy to parse format. Extract it and get leaked memory bytes.
So,
- Generate a PoC;
- Upload it to your avatar on vulnerable application;
- Save resulting png/jpg/gif image;
- Extract data from image.
ttffdd wrote a simple easy to use tool for this vulnerability called XBadManners. It generates a PoC and recovers leaked data from image.
Notice! That ImageMagick is a smart library and you can upload a poc.png which contains XBM image data to the server and if the image type is not checked properly, then ImageMagick will process poc.png as an XBM image. So if you just check the filetype of the uploaded file for the “*.png” matches, then this will not save you.
Part 2 — Is ImageMagick secure?
Short answer — probably not.
It is not the first serious vulnerability found in ImageMagick software. There are plenty of vulnerabilities. ImageMagick has almost 500 known fixed vulnerabilities! Every month there are new vulnerabilities found that may be difficult to exploit or not applicable, and a couple of times a year some serious vulnerabilities with high impact show up.
Here is a top list of widely known ImageMagick vulnerabilities.
ImageTragick. The most famous series of vulnerabilities in ImageMagick. It includes RCE, SSRF, Local File Read/Move/Delete in svg and mvg files. It was discovered in April 2016 by stewie and Nikolay Ermishkin.
- CVE-2016–3714 — RCE
- CVE-2016–3718 — SSRF
- CVE-2016–3715 — File deletion
- CVE-2016–3716 — File moving
- CVE-2016–3717 — Local file read
Patch was available in 6.9.3–9 released 2016–04–30 ImageMagick version. This vulnerability was quite popular with bughunters:
CVE-2017–15277 a.k.a. gifoeb. Discovered by Emil Lerner in 2017 July. This vulnerability is a memory leakage in GIF images processing. ImageMagick leaves the palette uninitialized if neither global nor local palette is present, and a memory leak occurs exactly through the palette. This rather limited the length of the leaked data. This vulnerability was also popular with bughunters.
GhostScript Type Confusion RCE (CVE-2017–8291). Was discovered in May 2017. It’s not an ImageMagick vulnerability, but it affects it as ImageMagick uses ghostscript to handle certain types of images with PostScript, i.e. EPS, PDF files.
CVE-2018–16509, another RCE in GhostScript, was published in August 2018. Also affects ImageMagick as it is in GhostScript like the previous bug.
How many other vulnerabilities that carry serious security problems remain unknown? We do not know. We have specially prepared a small history of ImageMagick security infographic.
Part 3 — How can we use ImageMagick in a secure way?
Stop using ImageMagick? Maybe, but..
We do not tell you to stop using the ImageMagick. We advise you to do this in a safe way to reduce information security risks.
First, as you may have noticed ImageMagick has a lot of vulnerabilities constantly appearing and therefore it is also updated frequently. If you use ImageMagick then watch for new versions and make sure the latest version is installed at all times. Notice that ImageMagick is not frequently updated in official repositories so it may contain old vulnerable versions. It is best to install stable ImageMagick version from source code.
But as you can see from our example, fixing old vulnerabilities brings new vulnerabilities :)
Therefore, updating ImageMagick may not save you.
Best practice for ImageMagick is to run it in an isolated environment, like Docker. Set minimum required rights for the service that uses ImageMagick. Put it in an isolated network segment with minimal network rights. And use this isolated environment ONLY for a specific task of processing custom user images using ImageMagick.
Also ImageMagick have configured security policy.
Here you can find a detailed guide on the security of ImageMagick from developers.
whoweare:
