As per the page you linked, there's a workaround.
Add the following to your policy.xml
:
<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" />
This file can be found in /etc/ImageMagick/
.
This prevents the ImageMagick coder modules from leveraging the access modules above, each of which are currently vulnerable to the command injection issue.
There are a number of documented PoCs for the bug over at the oss-security thread, which can be used as a check to validate whether the bug is still present after applying the workaround.
Here are a couple examples:
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>
Simply running convert
against these will cause ls -la
to be executed, the output of which will be displayed in your console if the vulnerability is present.