On 29th May, we were alerted to a new ImageMagick vulnerability(NOT ImageTragick which we covered earlier) that allows arbitrary code execution on web hosting servers running Apache, Nginx or others as long as ImageMagick binary “convert” is accessible to web servers. We confirmed this vulnerability in several Linux web hosting servers including cPanel, Plesk and DirectAdmin.

What is ImageMagick popen() shell vulnerability?

Arbitrary shell code can be passed to ImageMagick program as part of a file name using pipe ( | ) as the first character.

For eg., the “convert” command usually works like this:

user1@sev [~/public_html]$ convert image.jpg image.png

Instead, as the following section shows, the shell code “rm” will be executed is “|” is given as the first character:

What are the solutions available?

Till now, there’s no official announcement from ImageMagick on how this vulnerability can be patched. Various vendors have acknowledged this vulnerability using CVE ID CVE-2016-5118. As of now, no one has released patches yet.

For now, the best course of action is to limit which all users (or applications) can access ImageMagick, and limit the permissions of those users to execute shell commands.

How we block exploits that use popen () vulnerability

Emergency reaction to security threats (aka Zero-day threat mitigation) like this are a part of our Preventive Server Management Services and Dedicated Support Services. Our engineering teams are right now securing our client servers on a case-to-case basis depending on ImageMagick dependencies and server configuration.

This vulnerability is mitigated in the following 3 ways:

Patching the ImageMagick program to disable the HAVE_POPEN function in “blob.c” file.

1. Patching ImageMagick

This solution is not officially supported, but our server engineering team is testing this solution in our labs, and applying the patch on a case by case basis on individual websites that use ImageMagick quite heavily.

2. Restricting web server permissions

The shell commands that can be accessed by web server can be restricted using Apache/PHP/Nginx/Linux configuration files. These restrictions are now being reviewed, and specific rules are added for new servers.

3. Blocking command execution using Web Application Firewalls

We’ve secured a lot of our client’s servers using Web Application Firewalls like ModSecurity and NAXSI. These firewalls sit between the internet and the web server giving a layer of security based on configurable rule set.