Re: GraphicsMagick Response To "ImageTragick"

[Simon McVittie <smcv () debian org>]

On Mon, 09 May 2016 at 08:29:40 -0500, Bob Friesenhahn wrote:
> 1. CVE-2016-3714 - Insufficient shell characters filtering
>
>    GraphicsMagick is not susceptible to remote code execution except
>    if gnuplot is installed (because gnuplot executes shell commands).
>    Gnuplot-shell based shell exploits are possible without a gnuplot
>    file being involved although gnuplot invokes the shell.  To fix
>    this, the "gplt" entry in the delegates.mgk file must be removed.

I think this should perhaps have a separate CVE ID assigned: it's the
same impact (arbitrary code execution) and was discovered at around
the same time, but the mechanism is not similar to the
missing/insufficient quoting/escaping for ImageMagick's %M placeholder,
which was the root cause of (the original incarnation of) CVE-2016-3714.

In GraphicsMagick this was the "GPLT" format, removed in hg commit
"Gnuplot files are inherently insecure. Remove delegates support for
reading them."
https://sourceforge.net/p/graphicsmagick/code/ci/45998a25992d1142df201d8cf024b6c948b40748/

In ImageMagick this was the "PLT" format, removed in this git commit with
the misleading commit message "Update to the latest autoconf/automake":
https://github.com/ImageMagick/ImageMagick/commit/e87116ab2bd070c47943d4118a18c8f3a47461e2

MITRE, do you consider this to be:

* part of CVE-2016-3714,
* a single separate vulnerability to which both GraphicsMagick and ImageMagick
  were vulnerable, or
* two separate vulnerabilities, one in each package?

> 2. CVE-2016-3718 - SSRF
>
>    GraphicsMagick has always supported HTTP and FTP URL requests from
>    the context of the executing process if it is linked with libxml2.
>    There is no sandboxing or policy to determine which HTTP and FTP
>    URLs should be allowed/denied because they should only be available
>    from outside the system, or in the public space outside
>    a "firewall".

I'm not sure whether I'm understanding "because they should..."
correctly.

To be clear, are you saying that running GraphicsMagick code on a host
that is whitelisted in someone's IP address ACL, has access to a LAN
where the wider Internet does not, or has private services on the
loopback interface is not a supported situation?

Is there a subset of "safe" image formats that is known not to induce
these requests, and where they *would* be considered to be a bug?  I would
be surprised if this happened when resizing or manipulating common bitmap
formats like JPEG, PNG, GIF, BMP, and one of the mitigations recommended
on imagetragick.com has been to limit the formats that will be accepted.

> 4. CVE-2016-3716 - File moving
>
>     This is a two-factor attack and is actually file copying.  It is
>     not successful using GraphicsMagick.  MSL is an XML-based "script"
>     format which should never be allowed to be submitted and invoked
>     by an untrusted party.

Is there any situation where GraphicsMagick will interpret a file of
unspecified format as MSL, for instance recognizing it by extension or
magic number?

Thanks,
    S