Según la página vinculada, hay una solución .
Agregue lo siguiente a su 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" />
Este archivo se puede encontrar en /etc/ImageMagick/ .
Esto evita que los módulos del codificador ImageMagick aprovechen los módulos de acceso anteriores, cada uno de los cuales es actualmente vulnerable al problema de la inyección de comandos.
Hay una serie de PoC documentados sobre el error en el hilo de oss-security , que se puede usar como una verificación para validar si el error sigue presente después de aplicar la solución.
Aquí hay algunos ejemplos:
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>
La simple ejecución de convert contra estos hará que se ejecute ls -la , cuya salida se mostrará en su consola si la vulnerabilidad está presente.