Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 May 2016 13:53:28 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss-security@...ts.openwall.com
Subject: Re: GraphicsMagick Response To "ImageTragick"

On Mon, 9 May 2016, Simon McVittie wrote:
>
>> 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?

The SVG and MVG formats are able to submit http and ftp URL requests. 
The allowed URLs are not restricted by policy as they would be if SVG 
was running in a web browser.  My point is that the URLs are requested 
from the perspective of the user id and host where the process is 
running.  If this is on the back-side of a firewall, then it may be 
possible to access URLs which otherwise could not be accessed.

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

Outside of the utilities themselves, or applications based on the 
libraries, only SVG, MVG, and MSL (Magick Scripting Language) are able 
to submit URL requests.  MSL should be viewed as a scripting format 
rather than being a file format.

>> 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?

There is no detection of MSL by its header but the MSL reader will be 
dispatched to by a .MSL extension.  It requires adding only one line 
of code to block responding to the MSL extension.

There has been little mention of SVG, but in both GraphicsMagick and 
ImageMagick the native SVG renderer works by pre-processing SVG into a 
MVG file.  The MVG file is then executed.  The SVG pre-processor is 
not very robust so it is possible to inject arbitrary strings from the 
SVG into MVG, and (with correct quoting) insert new commands into the 
MVG stream.  Due to this, MVG needs to behave securely while it is 
executing MVG delivered from SVG.  Otherwise it is my opinion that MVG 
is an internal implementation format (not a file exchange format) 
which should be allowed to support extensions peculiar to 
GraphicsMagick and is not a scary dangerous thing.

The focus of https://imagetragick.com/ on MVG has brought attention to 
it, and tarnished its reputation, but (provided it is not executed by 
default) the focus should be on assuring that formats assumed to be 
secure (e.g. SVG and WMF) are read/rendered securely.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ