[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160509193355.GA11234@perpetual.pseudorandom.co.uk>
Date: Mon, 9 May 2016 20:33:55 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: GraphicsMagick Response To "ImageTragick"
For context: I co-maintain ikiwiki, a wiki engine that uses the
Image::Magick Perl bindings to resize potentially-attacker-supplied images
(although I'm considering supporting both, and potentially trying to load
Graphics::Magick first). I suspect that many ImageMagick and GraphicsMagick
users are in an analogous situation.
On Mon, 09 May 2016 at 13:53:28 -0500, Bob Friesenhahn wrote:
> 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.
Thanks for clarifying!
> 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.
Great. Is there an API that can be used to say "load this arbitrary file,
but only if it is in a format that is considered entirely safe"?
(Safe in the sense that it isn't vulnerable to SSRF, doesn't perform
arbitrary actions like MSL does, can't recurse into a separate
resource that might not be safe, and so on, in a way that won't
become insecure by the addition of another format.)
At the moment my mitigation for these vulnerabilities is refusing to
resize images that don't end with .jpg .jpeg .png or .gif, refusing
to resize images that have one of those extensions but don't have the
matching magic number, and invoking ImageMagick APIs with an argument
like "jpeg:myfile.jpg" to force the use of the expected coder. This
doesn't seem like something that every developer is going to get right
in practice.
> > > 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.
I think it might be necessary to add that one line of code, if rendering a
SVG that contains <xi:include> directives can result in interpreting
an accompanying .msl script. On the other hand, if SVGs are open to SSRF
by design, many services will need to avoid processing an attacker-supplied
SVG anyway, so perhaps the set of services that are willing to process SVGs
from untrusted users is negligible...
> 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.
I think the reason people are surprised and concerned to read about the
MVG and MSL scripting languages is that they enter *Magick through the
same APIs that open "safe" image files, blurring the boundary between
"open a file" and "execute a script". If the entry point into executing
MVG/MSL scripts was named more like ExecuteScript(), as opposed to
ReadImage(), then I don't think anyone would object to MVG and MSL
files having arbitrary code execution capabilities.
It's the same concern as when office suites' document formats gain support
for auto-running macros when opened, or when operating systems start
auto-running scripts and executables when removable media are inserted -
an action that was previously considered to be mostly safe to perform
on untrusted content unexpectedly becomes an act of trust.
S
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.
