Date: Mon, 9 May 2016 18:20:46 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: GraphicsMagick Response To "ImageTragick" 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ