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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ