One of the greatest features of ImageMagick is one of its greatest downfalls too. The support of more than 100 different formats means there’s 100 different attack vectors. And with that, a whole flurry of different vulnerabilities have come out from ImageMagick.
In 2016, ImageTragick saw the release of five different CVEs related to filesystem access from just converting an arbitrary image from one image format to another. In late 2016 and 2018, Tarvis Ormandy showed how it was possible to get remote code execution through the parsing of GhostScript. In 2020, Alex Inführ found RCE through a PDF password parameter. This month, a team at Metabase Q identified a method of local file inclusion when converting PNGs. The list goes on and on…
However, when this incredibly powerful tool is just a simple apt install away, it’s very easy for it to be deployed without much consideration for security.
When you install ImageMagick, a particular sentence may stand out to those in the security industry:
Chances are most people completely skip over this line on the download page (especially if you install via a package manager). A security policy within ImageMagick allows developers to configure and limit what file types should be processed by the application. Realistically, most applications probably only intend to support a few file types (such as JPEG, PNG, GIF, etc.) and most security vulnerabilities within ImageMagick relate to obscure or complex formats (such as GhostScript, SVGs, MVGs, etc.)
The web application we assessed allowed users to upload PNGs and JPGs. After being uploaded, we noticed that they were converted to JPEGs. Alarm bells started going off when we noticed that the images were being processed, as we know ImageMagick is a common tool used for this. We noticed that the application checked the MIME type of an uploaded file and that the file extension matched, i.e. the file name had to end in .png or .jpg and specify the image/jpeg or image/png MIME type. Yet, when we modified the request to upload an SVG, the application continued to convert our images like we had uploaded JPGs or PNGs…
In a default configuration, RMagick will automatically determine the file type of an image from looking at the content of the file, rather than the file name like a developer might expect.
The following Ruby code shows roughly what the endpoint was doing that we exploited:
post ‘/upload’ do
All it took was for us to upload a malicious SVG containing a local file inclusion payload, change the extension and MIME type and a lovely image of /etc/passwd was returned to us! (On a side note, did you know AWS WAF only checks the first 8KB of a POST request?)
Content-Disposition: form-data; name=“awswafbypass”; filename=“coolfile.jpg”
AAAAAAAAAA… //8kb of these for bypass——WebKitFormBoundary6KiSss4GgOPvCI9D
Content-Disposition: form-data; name=“file”; filename=“coolfile.jpg”
<svg width=“1000” height=“1000” xmlns:xlink=“http://www.w3.org/1999/xlink”> xmlns=“http://www.w3.org/2000/svg”>
<image xlink:href=“text:/etc/passwd“ width=“1000” height=“1000” />
If you use ImageMagick within your web application, make sure you’re using a strict security policy! Security policies will likely block many vulnerabilities related to ImageMagick, limiting the attack surface of your application. Regular web application penetration testing and security consultancy services can vastly help organisations lower the risk of their exposed applications.