[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.GSO.2.20.1605091330140.27960@freddy.simplesystems.org>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
