Bugzilla – Bug 978061
VUL-0: ImageMagick: CVE-2016-3714, CVE-2016-3715, CVE-2016-3716, CVE-2016-3717, CVE-2016-3718 (IMAGETRAGICK)
Last modified: 2016-05-30 09:33:11 UTC
bugbot adjusting priority
More from the list: It isn't only MVG "feautres" but also ImageMagick's SVG (if ImageMagick compiled without --with-rsvg it internally converts SVG files to MVG) and maybe some other formats, if they supports external image include. Also ImageMagick detects file type by it's content, so you can change MVG file name to image.jpg, and "don't process untrusted MVG files" may be not so easy. ImageMagick developers thinks that the best solution is safe configuration in policy.xml (https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t= 26801) and temporary workaround before good fix rce fix: Until we get a proper fix, either remove the https delegate from delegate.xml or remove the rights for using the HTTPS delegate in policy.xml <policy domain="coder" rights="none" pattern="HTTPS" /> I sent this message with Apple Mail, I hope it hasn t html part. On 02 May 2016, at 20:09, Kurt Seifried <kseifried@redhat.com> wrote: Ah sorry I just saw the starting wall of html and closed it out. So I just finished reading docs on MVG, holy hell, what a disaster of "features". 1. Insufficient shell characters filtering leads to (potentially remote) code execution Please use CVE-2016-3714 for this issue 2. SSRF I'm not sure if this is a bug or a feature, e.g. it appears to be intentional (fill pattern from url). I think like Python Pickle it boils down to a dangerous feature you shouldn't use on untrusted data, as such it's not CVE worthy for the original library, but might be if a specific app is vulnerable to this. Is there any documentation one way or the other that talks about this downloading stuff/how it downloads it specifically? Does it respect/ properly handle HTTPS for example? 3. File deletion On this one I'm inclined to CVE it due to the ability for an attacker specified path in the MVG. Please use CVE-2016-3715 for this issue 4. File moving On this one I'm inclined to CVE it due to the ability for an attacker specified path in the MVG. Please use CVE-2016-3716 for this issue 5. Local file read (independently reported by original research author - https://hackerone.com/stewie) On this one I'm inclined to CVE it due to the ability for an attacker specified path in the MVG. Please use CVE-2016-3717 for this issue Also might I suggest these aren't really worth embargo and that ideally guidance like "don't process untrusted MVG files" be offered. On Mon, May 2, 2016 at 9:48 AM, Solar Designer <solar@openwall.com> wrote: On Mon, May 02, 2016 at 09:15:38AM -0600, Kurt Seifried wrote: > Can you resend as text instead of HTML? It got horribly mangled. Kurt, Nikolay's message contained both text/plain and text/html parts. The text/plain part looks OK to me (not mangled) - perhaps you'll want to look at this one. (Resending without a text/html part at all would also be OK.) Alexander -- -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert@redhat.com Nikolay Ermishkin, Mail.Ru Security Team
"Please use CVE-2016-3718 for the ImageMagic MVG 2. SSRF"
https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588
The bug has a website: https://imagetragick.com/
This has now been disclosed due to exploits being posted onto public forums.
I am working on a update that should prevent the risk on default installs with out breaking almost all usecases. I am recompiling with the --with-rsvg=yes (we were build requiring the header file but not actually enabling the support) this will mean that svg files will not be affected, there is more info on how someone might use the disabled coders here https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=29594
bobfriesenhahn 11:26 AM While it pre-dates my involvement with ImageMagick, the '@' symbol exists in order to deal with command line length problems. The content of a file name prefixed with '@' is read in as arguments (substituted) wherever it appears. For example 'filename' might contain a list of 1000 files. There is also support for this dereferencing for the drawing primitive passed to the DrawImage() function. Given the possibility of a file delivered via some other means, this might be an exploit mechanism, but I am not sure how.
More info from slack re GraphicsMagick: bobfriesenhahn is the GraphicsMagick maintainer bobfriesenhahn 11:45 AM At the moment, GraphicsMagick only grants access to coders via a MAGICK_CODER_STABILITY environment variable (which puts formats in three classes based on my own judgement) and at the C/C++ program level by allowing a program to register a call-back function which blesses access to any file. GraphicsMagick got there first but ImageMagick has done a more detailed job by providing a configuration file. 11:47 env MAGICK_CODER_STABILITY=PRIMARY gm convert -list formats |wc -l 84 11:47 env MAGICK_CODER_STABILITY=BROKEN gm convert -list formats |wc -l 199
Releative to GraphicsMagick: bobfriesenhahn 12:07 PM A distro maintainer can easily modify the sources via a patch. In order to make a format disappear by default, modify the RegisterFOOImage function for the support source module in the 'coders' directory and add this: 'entry->coder_class=BrokenCoderClass'. Users can still run it if they can set the MAGICK_CODER_STABILITY environment variable to 'BROKEN'. In the next release there will be a EnableBrokenCoders define which could be used to block out compilation of all code in the module. bobfriesenhahn 12:15 PM In order to be more conservative, a maintainer could change the default value of MinimumCoderClass in magick/magick.c (e.g. to StableCoderClass). This would likely make some users angry since some things would stop working by default. Please note that recent security issues fixed in GraphicsMagick do not necessarily align with the coder stability levels. For example, XPM (marked as Stable) has taken an unexpected amount of effort to solidify and SVG/MVG still has a few issues to be fixed for the next release.
I have a package for SLE 12 here https://build.suse.de/project/show/home:simotek:branches:OBS_Maintained:ImageMagick Unfortunatly SLE-10+SLE-11 versions are quite old, old enough in fact to not support policy.xml at all, Adding to the problem here when upstream migrated from svn to git they didn't migrate there history http://git.imagemagick.org/repos/ImageMagick/tree/master and this feature was added before there was proper version history From the changelog: 2009-05-04 6.5.2-1 Chris Madison <madisonblu@gmail...> * Accept file lists on the command line (e.g. echo "rose: rose.png" | convert @- ...). * Duplicate line in tiff.c breaking read of zip compressed tif (reference http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=13688). * Support policies to permit or deny any coder, delegate, filter, or file path (see policy.xml). 2009-05-02 6.5.2-0 Chris Madison <madisonblu@gmail...> Is the only place where policy.xml is mentioned although there are a number of changes since, at this point I think it would be far safer to consider updating SLE-11 and SLE-10 if required to the version available for SLE-12
https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=29594#p132782 refers to https://github.com/ImageMagick/ImageMagick/commit/2c04b05f205b5198f4c01b0c86097cba2b218fcf https://github.com/ImageMagick/ImageMagick/commit/091b7b46e132cd7b4142e7b81ac7764502c7e08b Adds %F.
(In reply to Petr Gajdos from comment #15) > https://www.imagemagick.org/discourse-server/viewtopic. > php?f=2&t=29594#p132782 > > refers to > > https://github.com/ImageMagick/ImageMagick/commit/ > 2c04b05f205b5198f4c01b0c86097cba2b218fcf > https://github.com/ImageMagick/ImageMagick/commit/ > 091b7b46e132cd7b4142e7b81ac7764502c7e08b > > Adds %F. These patches still require <policy domain="path" rights="none" pattern="@*" /> in the policy file which currently doesn't exist on SLE-10 or SLE11
was posted to oss-sec Subject: [oss-security] ImageMagick Is On Fire -- CVE-2016-3714 There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild. A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP's imagick, Ruby's rmagick and paperclip, and nodejs's imagemagick. If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities by doing at least one these two things (but preferably both!): 1. Verify that all image files begin with the expected "magic bytes" corresponding to the image file types you support before sending them to ImageMagick for processing. (see FAQ for more info) 2. Use a policy file to disable the vulnerable ImageMagick coders. The global policy for ImageMagick is usually found in "/etc/ImageMagick". This policy.xml example will disable the coders EPHEMERAL, URL, MVG, and MSL. Github Gist showing an example policy file: https://gist.github.com/rawdigits/d73312d21c8584590783a5e07e124723 FAQ Who found this bug? Stewie (https://hackerone.com/stewie) found the initial bug, and Nikolay Ermishkin (https://twitter.com/__sl1m) from the Mail.Ru Security Team found additional issues, including the RCE. Will you share the exploit with me? No. We would like to give people a chance to patch before it is more widely available. The exploit is trivial, so we expect it to be available within hours of this post. Updates and PoC will eventually be available here. Are patches available? Yes, but they appear to be incomplete. Everyone would have preferred to wait for patches before disclosing, but working exploits are readily available. What are "magic bytes"? The first few bytes of a file can often used to identify the type of file. Some examples are GIF images, which start with the hex bytes "47 49 46 38", and JPEG images, which start with "FF D8". This list on Wikipedia has the magic bytes for most common file types. Why are you disclosing a vulnerability like this? We have collectively determined that these vulnerabilities are available to individuals other than the person(s) who discovered them. An unknowable number of people having access to these vulnerabilities makes this a critical issue for everyone using this software. ImageMagick also disclosed this on their forum a few hours ago. How well-tested are these mitigations? They are effective against all of the exploit samples we've seen, but we cannot guarantee they will eliminate all vectors of attack. Are there other ways to mitigate? Sandboxing ImageMagick is worth investigating, but we are not providing specific instructions for doing this. What else should I know? We did not find this vulnerability ourselves. We understand the mechanisms involved, but credit for finding this vulnerability should go to the researcher(s). Vulnerabilities need names! What is its name??!? If you must, we've been calling it "ImageTragick". How can I contact you? imagetragick@gmail.com -- Ryan Huber rhuber@gmail.com @ryanhuber https://github.com/rawdigits +1 (312) 380 6136
<policy domain="coder" rights="none" pattern="EPHEMERAL" /> <policy domain="coder" rights="none" pattern="HTTPS" /> <policy domain="coder" rights="none" pattern="MVG" /> <policy domain="coder" rights="none" pattern="MSL" /> <policy domain="coder" rights="none" pattern="TEXT" /> Do I understand correctly, that this workaround turns out coders entirely? If so, would be an equivalent to split separate package with these delegates and do not install it by default? delegates probably maps to: mvg.c, msl.c, miff.c, txt.c, url.c
(In reply to Petr Gajdos from comment #18) > <policy domain="coder" rights="none" pattern="EPHEMERAL" /> > <policy domain="coder" rights="none" pattern="HTTPS" /> > <policy domain="coder" rights="none" pattern="MVG" /> > <policy domain="coder" rights="none" pattern="MSL" /> > <policy domain="coder" rights="none" pattern="TEXT" /> > > Do I understand correctly, that this workaround turns out coders entirely? > If so, would be an equivalent to split separate package with these delegates > and do not install it by default? > > delegates probably maps to: mvg.c, msl.c, miff.c, txt.c, url.c Yes I believe that would also work, however we will still need to build with librsvg support as currently provided by mvg, while customers probably aren't using mvg its highly likely some are using svg.
(In reply to Simon Lees from comment #19) > Yes I believe that would also work, however we will still need to build with > librsvg support as currently provided by mvg, while customers probably > aren't using mvg its highly likely some are using svg. Yes, nevertheless -- how it would be hard to add rsvg support? I mean, it seems that there is almost just one function involved, ReadSVGImage() with few rsvg_* calls. The diff of coders/svg.c between 10sp3 and 11 have around 1500 lines. Or, we could unify just versions on 11 and 10sp3? Do not get me wrong: 1. I would be the happiest maintainer of ImageMagick in the world if we would unify versions on all sleses, if possible. Just looking for possibilities. 2. I am not sure about the shortest time solution.
sle11: [ 91s] RSVG --with-rsvg=yes yes
So the plan for 11 is: $ convert exploit.mvg out.png convert: no decode delegate for this image format `exploit.mvg'. convert: missing an image filename `out.png'. $ $ MAGICK_CODER_MODULE_PATH=/usr/lib64/ImageMagick-6.4.3/modules-Q16/coders/vulnerable/ convert exploit.mvg out.png sh: curl: command not found total 24 drwxr-xr-x 2 root root 4096 2016-05-05 12:38 . drwxr-xr-x 25 root root 4096 2016-05-05 12:08 .. -rw-r--r-- 1 root root 108 2016-05-03 11:07 delete_file.mvg -rw-r--r-- 1 root root 113 2016-05-03 10:55 exploit.mvg -rw-r--r-- 1 root root 385 2016-05-03 10:55 exploit.svg -rw-r--r-- 1 root root 3049 2016-05-05 12:38 out.png convert: unrecognized color `https://example.com/image.jpg"|ls "-la'. convert: unable to open image `/tmp/magick-XXMIEnTc': No such file or directory. convert: unable to open file `/tmp/magick-XXMIEnTc': No such file or directory. convert: Non-conforming drawing primitive definition `fill'. $ Ok?
https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=29594#p132782 "The indirect reads were coming from the MVG and MSL coders, so denying the right to use these coders should be sufficient to prevent exploits. Denying indirect reads with a path policy and a pattern of "@*" is supported in ImageMagick 6.9.3-10 and ImageMagick 7.0.1-1 for those that need to utilize the MVG and MSL coders." So <policy domain="path" rights="none" pattern="@*" /> is not neccessary when mvg and msl coders are disabled.
https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588 talks about removing https from delegates.xml. Do we want too?
(In reply to Petr Gajdos from comment #25) > https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588 > talks about removing https from delegates.xml. Do we want too? Disabling it in the policy.xml is enough: <policy domain="coder" rights="none" pattern="HTTPS" /> We'll disable it in the policy.xml (where it's implemented) or by removing the delegates (older distributions).
Okay. Package for 11 submitted.
This is an autogenerated message for OBS integration: This bug (978061) was mentioned in https://build.opensuse.org/request/show/393904 13.2 / ImageMagick
This is an autogenerated message for OBS integration: This bug (978061) was mentioned in https://build.opensuse.org/request/show/393906 Factory / ImageMagick
There is 6.4.3-6 in home:pgajdos:maintenance:ImageMagick/ImageMagick.SUSE_SLE-10-SP3_Update_Test. The ImageMagick-rsvg-detect.patch is very hasty, quick and dirty, I could not get pkg-config wheels going to detect rsvg so far before leave. It does not call autoreconf. While trying to convert regular svg file I get: $ convert svg-viewer.svg out.png convert: unable to close module `SVG': /opt/gnome/lib64/libORBit-2.so.0: undefined symbol: CORBA_ORB_destroy. $ But out.png is readable and seems to display the same as svg-viewer.svg. Feel free to grab the package and improve it.
Created attachment 675897 [details] diff between configure results between 6.2.5 and 6.4.3 on 10sp3 Do you think any issue manifest itself there?
(In reply to Petr Gajdos from comment #31) > While trying to convert regular svg file I get: > > $ convert svg-viewer.svg out.png > convert: unable to close module `SVG': /opt/gnome/lib64/libORBit-2.so.0: > undefined symbol: CORBA_ORB_destroy. > $ Not sure about this one. Dominique, have you idea?
$ objdump -T /opt/gnome/lib64/libORBit-2.so.0 | grep CORBA_ORB_destroy 000000000002cb10 g DF .text 00000000000001a0 Base CORBA_ORB_destroy $
The Policy Map was updated again on 5/5 <policymap> <policy domain="coder" rights="none" pattern="EPHEMERAL" /> <policy domain="coder" rights="none" pattern="URL" /> <policy domain="coder" rights="none" pattern="HTTPS" /> <policy domain="coder" rights="none" pattern="MVG" /> <policy domain="coder" rights="none" pattern="MSL" /> <policy domain="coder" rights="none" pattern="TEXT" /> <policy domain="coder" rights="none" pattern="SHOW" /> <policy domain="coder" rights="none" pattern="WIN" /> <policy domain="coder" rights="none" pattern="PLT" /> </policymap> It also contains a list of repeaters
Reference? (In reply to Simon Lees from comment #35) > <policymap> > <policy domain="coder" rights="none" pattern="EPHEMERAL" /> > <policy domain="coder" rights="none" pattern="URL" /> > <policy domain="coder" rights="none" pattern="HTTPS" /> > <policy domain="coder" rights="none" pattern="MVG" /> > <policy domain="coder" rights="none" pattern="MSL" /> > <policy domain="coder" rights="none" pattern="TEXT" /> > <policy domain="coder" rights="none" pattern="SHOW" /> > <policy domain="coder" rights="none" pattern="WIN" /> > <policy domain="coder" rights="none" pattern="PLT" /> > </policymap> And LAUNCH no? Weird :). Should not this be GPLT? I do not see PLT anywhere. sle 11: For EPHEMERAL, SHOW and WIN: it will probably need to be forbidden via patch in ./magick/image.c, am going to test.
(In reply to Petr Gajdos from comment #36) > sle 11: For EPHEMERAL, SHOW and WIN: it will probably need to be forbidden > via patch in ./magick/image.c, am going to test. EPHEMERAL is not handled there. Only WIN and SHOW.
(In reply to Petr Gajdos from comment #36) > Reference? https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588 I need reproducers for WIN and SHOW.
This is an autogenerated message for OBS integration: This bug (978061) was mentioned in https://build.opensuse.org/request/show/394009 13.2 / ImageMagick
Package for 11 submitted. I tested like this: # convert should bail when there is no delegate $ convert exploit.mvg out.png convert: no decode delegate for this image format `exploit.mvg'. convert: missing an image filename `out.png'. $ # convert will expose the vulnerability when MAGICK_MODULE_PATH point also # on directory, where are disabled modules $ MAGICK_CODER_MODULE_PATH='/usr/lib64/ImageMagick-6.4.3/modules-Q16/coders:/usr/lib64/ImageMagick-6.4.3/modules-Q16/coders/vulnerable/' convert exploit.mvg out.png sh: curl: command not found total 24 drwxr-xr-x 2 root root 4096 2016-05-06 11:02 . drwxr-xr-x 25 root root 4096 2016-05-06 11:00 .. -rw-r--r-- 1 root root 80 2016-05-06 10:19 delete_file.mvg -rw-r--r-- 1 root root 113 2016-05-03 10:55 exploit.mvg -rw-r--r-- 1 root root 385 2016-05-03 10:55 exploit.svg -rw-r--r-- 1 root root 3049 2016-05-06 10:50 out.png convert: unrecognized color `https://example.com/image.jpg"|ls "-la'. convert: unable to open image `/tmp/magick-XXAfKLoo': No such file or directory. convert: unable to open file `/tmp/magick-XXAfKLoo': No such file or directory. convert: Non-conforming drawing primitive definition `fill'. $ # convert should convert a harmless svg file correctly $ display svg-viewer.svg $ convert svg-viewer.svg svg-viewer.png $ display svg-viewer.png # delegates.xml should not contain %l at all (I have no testcase # for WIN and SHOW coders) $ grep '%l' /usr/lib64/ImageMagick-6.4.3/config/delegates.xml $ # delegates.xml should not contain 'plt' string $ grep 'plt' /usr/lib64/ImageMagick-6.4.3/config/delegates.xml $ HTH
I have commited also changes to 10sp3 package into home:pgajdos:maintenance:ImageMagick/ImageMagick.SUSE_SLE-10-SP3_Update_Test The testing can be basically the same as in comment 43, except the error of closing the module I have pointed out already: $ convert svg-viewer.svg svg-viewer.png convert: unable to close module `SVG': /opt/gnome/lib64/libORBit-2.so.0: undefined symbol: CORBA_ORB_destroy. $ It comes from module.c:InvokeDynamicImageFilter() where lt_dlclose() at the end of the function in question fails for the reason it prints. To be honest I have no quick idea right now how to debug it given that the library contains the symbol (comment 34). Also, someone need to decide if we want the update for 10sp3 at all. See you on monday's evening.
SUSE-SU-2016:1260-1: An update that fixes 5 vulnerabilities is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3716,CVE-2016-3717,CVE-2016-3718 Sources used: SUSE Linux Enterprise Workstation Extension 12-SP1 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Workstation Extension 12 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Software Development Kit 12 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Server 12-SP1 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Server 12 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Desktop 12-SP1 (src): ImageMagick-6.8.8.1-19.1 SUSE Linux Enterprise Desktop 12 (src): ImageMagick-6.8.8.1-19.1
openSUSE-SU-2016:1261-1: An update that fixes 5 vulnerabilities is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3716,CVE-2016-3717,CVE-2016-3718 Sources used: openSUSE 13.2 (src): ImageMagick-6.8.9.8-18.1
openSUSE-SU-2016:1266-1: An update that fixes 5 vulnerabilities is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3716,CVE-2016-3717,CVE-2016-3718 Sources used: openSUSE Leap 42.1 (src): ImageMagick-6.8.8.1-9.1
https://sourceforge.net/p/graphicsmagick/mailman/message/35072963/ This the GraphicsMagick project response to the unfortunate list of ImageMagick exploits listed on the web site at https://imagetragick.com/. While GraphicsMagick forked from ImageMagick in 2002, it is reasonable to expect that much of the internal operation and architecture is still similar. In fact, some of the claimed exploits (or similar) are relevant to GraphicsMagick. Based on the current issues described, this is how GraphicsMagick fares: 1. CVE-2016-3714 - Insufficient shell characters filtering GraphicsMagick is not susceptible to remote code execution except if gnuplot is installed (because gnuplot executes shell commands). Gnuplot-shell based shell exploits are possible without a gnuplot file being involved although gnuplot invokes the shell. To fix this, the "gplt" entry in the delegates.mgk file must be removed. 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". 3. CVE-2016-3715 - File deletion While the syntax is different from ImageMagick, GraphicsMagick does support a file specification syntax "tmp:" which causes the input file to be deleted after it is read. This has limited use to hand off responsibility for a temporary file to another process in order to assure that the temporary file will be deleted once it is no longer needed. This feature will removed since it is not actually necessary any more. 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. 5. CVE-2016-3717 - Local file read GraphicsMagick supports a "txt:" file specification syntax which enables rendering all the lines of a text file as an image. There is also a "label:" file specification syntax which is capable of rendering only the first line of a file. Files ending with extension ".txt" are automatically rendered into an image. The main concern with this is that sensitive data in a text file might become rendered as an image on a web site. Using an uploaded manual page with file extension ".man" or by reading with "man:filename", the 'man' delegate can be used to render any file on the system into Postscript if 'groff' is installed. To resolve these concerns, several patches which should apply across most GraphicsMagick 1.3.XX releases have been developed and are attached: 1. Remove automatic detection/execution of MVG based on file header or file extension. [disable-mvg-ext.patch] 2. Remove the ability to cause an input file to be deleted based on a filename specification. [disable-tmp-magick-prefix.patch] 3. Improve the safety of delegates.mgk by removing gnuplot support, removing manual page support, and by adding -dSAFER to all ghostscript invocations. [delegates-safer.patch] 4. Sanity check the MVG image primitive filename argument to assure that "magick:" prefix strings will not be interpreted. Please note that this patch will break intentional uses of magick prefix strings in MVG and so some MVG scripts may fail. We will search for a more flexible solution. [image-sanity-check.patch] Please address any concerns to me (Bob Friesenhahn <bfriesen@...>).
Created attachment 676034 [details] GraphicsMagick: delegates-safer.patch
Created attachment 676035 [details] GraphicsMagick: disable-mvg-ext.patch
Created attachment 676036 [details] GraphicsMagick: disable-tmp-magick-prefix.patch
Created attachment 676037 [details] GraphicsMagick: image-sanity-check.patch
Created attachment 676129 [details] Reproducer for graphicsmagick file read To reproduce: gm convert graphicsmagick_file_read.mvg out2.png
Created attachment 676132 [details] graphicsmagick file delete reproducer touch out.png ls gm convert graphicsmagick_file_delete.mvg out2.png ls
This is an autogenerated message for OBS integration: This bug (978061) was mentioned in https://build.opensuse.org/request/show/394456 13.2+42.1 / GraphicsMagick
SUSE-SU-2016:1275-1: An update that fixes 5 vulnerabilities is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3716,CVE-2016-3717,CVE-2016-3718 Sources used: SUSE OpenStack Cloud 5 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Manager Proxy 2.1 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Manager 2.1 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Software Development Kit 11-SP4 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Server 11-SP4 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Server 11-SP3-LTSS (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Server 11-SP2-LTSS (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): ImageMagick-6.4.3.6-7.34.1 SUSE Linux Enterprise Debuginfo 11-SP2 (src): ImageMagick-6.4.3.6-7.34.1
SUSE-SU-2016:1276-1: An update that fixes four vulnerabilities is now available. Category: security (moderate) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3717,CVE-2016-3718 Sources used: SUSE Studio Onsite 1.3 (src): GraphicsMagick-1.2.5-4.35.1 SUSE Linux Enterprise Software Development Kit 11-SP4 (src): GraphicsMagick-1.2.5-4.35.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): GraphicsMagick-1.2.5-4.35.1
We got feedback from "LEIBNIZ RECHENZENTRUM" that the fix did NOT do the trick: ++++++++++++++++++++++++++++++++++++++++++++++++++ My customer applied the latest package updates to fix the "ImageTragick" sec. vulnerability on SLES 11 SP4. Unfortunately this doesn't seem to fix this security problem. I was able to reproduce it as follows: # rpm -qa --last | grep -i magick perl-PerlMagick-6.4.3.6-7.34.1 Wed May 11 18:23:16 2016 libMagickWand1-6.4.3.6-7.34.1 Wed May 11 18:23:16 2016 libMagickCore1-6.4.3.6-7.34.1 Wed May 11 18:23:15 2016 ImageMagick-6.4.3.6-7.34.1 Wed May 11 18:22:15 2016 The command was taken from: https://imagetragick.com/ Please note that the ";" was removed from the command after example.com" # convert 'https://example.com"|ls "-la' out.png total 16 drwxr-xr-x 2 root root 4096 May 12 10:42 . drwxrwxrwt 7 root root 4096 May 12 10:42 .. -rw-r--r-- 1 root root 0 May 12 10:38 dummy1.txt -rw-r--r-- 1 root root 0 May 12 10:38 dummy2.txt -rw-r--r-- 1 root root 0 May 12 10:38 dummy3.txt -rw-r--r-- 1 root root 5833 May 12 10:39 out.png convert: no decode delegate for this image format `/tmp/magick-XXXCQC15'. convert: missing an image filename `out.png'. Although the latest ImageMagick version is used, the execution of commands is still possible. ++++++++++++++++++++++++++++++++++++++++++++++++++
30261 execve("/bin/sh", ["sh", "-c", "\"curl\" -s -k -L -o \"/tmp/magick-30260a39cHmN1fPPx\" \"https://example.com\"|ls \"-la\""], [/* 117 vars */]) = 0 the shell handles the pipe in there and executes the ls.
the https delegate is not disabled, nor escaped in the update.
Thanks, Marcus. https removed from delegates.xml in sr#114479 Now $ convert 'https://example.com"|ls "-la' out.png convert: unable to open image `https://example.com"|ls "-la': No such file or directory. convert: missing an image filename `out.png'. $ Sorry for the omission.
.
For idiots like me, does that mean we will get new patches?
yes, there will be a new update. sle12 is I understand not affected ,as we did more fixes there.
SLE-12 and openSUSE aren't affected, HTTPS coder is there disabled by the policy.xml mechanism.
The patch which fixes the gplt vector also fixes a related vector in gs. The lack of -dSAFER when invoking Ghostscript allows for arbitrary file read/write. Sander Bos noticed that ImageMagick isn't affected by this bug. Given that the -dSAFER bug is specific to GraphicsMagick, I think a separate CVE should be assigned.
SUSE-SU-2016:1301-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714 Sources used: SUSE OpenStack Cloud 5 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Manager Proxy 2.1 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Manager 2.1 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Software Development Kit 11-SP4 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Server 11-SP4 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Server 11-SP3-LTSS (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Server 11-SP2-LTSS (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): ImageMagick-6.4.3.6-7.37.1 SUSE Linux Enterprise Debuginfo 11-SP2 (src): ImageMagick-6.4.3.6-7.37.1
Reassigning to security team.
An update workflow for this issue was started. This issue was rated as important. Please submit fixed packages until 2016-05-23. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/62757
openSUSE-SU-2016:1326-1: An update that fixes four vulnerabilities is now available. Category: security (important) Bug References: 978061 CVE References: CVE-2016-3714,CVE-2016-3715,CVE-2016-3717,CVE-2016-3718 Sources used: openSUSE Leap 42.1 (src): GraphicsMagick-1.3.21-5.1 openSUSE 13.2 (src): GraphicsMagick-1.3.20-3.1
think we are good?
For the issues with CVE's I think were good, no one has come up with better ways to solve the issues then the ones we have. These popped up again on the list this morning but i'm not sure how important they are so maybe you spoke a couple of hours to soon. It's trivial to generate SSRF payloads for the formats processed through html2ps and soffice. I'd also expect that SSRF is normal behavior for uniconvertor, and RCE is normal behavior for blender and povray, but I haven't verified. If those are all counted separately... No CVE assigned - SSRF via html2ps delegates ImageMagick: Not fixed GraphicsMagick: Not fixed RedHat: Not fixed Debian: Not fixed No CVE assigned - SSRF via soffice delegates ImageMagick: Not fixed GraphicsMagick: Not vulnerable RedHat: Not fixed Debian: Not fixed No CVE assigned - (assumed) SSRF via uniconvertor delegates ImageMagick: Not fixed GraphicsMagick: Not vulnerable RedHat: Not fixed Debian: Not fixed No CVE assigned - (assumed) RCE via blender delegate ImageMagick: Not fixed GraphicsMagick: Not vulnerable RedHat: Not fixed Debian: Not fixed No CVE assigned - (assumed) RCE via povray delegate ImageMagick: Fixed GraphicsMagick: Fixed RedHat: Not fixed Debian: Not fixed
the massive amount of helper binaries IM can call will make it very hard to secure. :/
I'm currently working with SuSE linux Enterprise Server 10. I don't see available patch for this server version. Does anyone have an idea how can I address the vulnerability issue? Also I tried to modify the delegates for HTTPS and it somehow address the problem for HTTPS but how about the 'Label' pseudo protocol.
Gerardo, SLES 10 only had ImageMagick on the SDK, which is no longer supported. option 1: deinstall ImageMagick option 2: you can edit /usr/lib64/ImageMagick-6.2.5/config/delegates.xml remove the https delegate line and also remove some problematic coders from usr/lib64/ImageMagick-6.2.5/modules-Q16/coders/ msl.la msl.so mvg.la mvg.so txt.la txt.so url.la url.so
(In reply to Marcus Meissner from comment #89) > and also remove some problematic coders from > usr/lib64/ImageMagick-6.2.5/modules-Q16/coders/ > msl.la > msl.so > mvg.la > mvg.so > txt.la > txt.so > url.la > url.so And svg also.
Closing again as for comment 89.