Re: ImageMagick vulnerability
| From: | Yasuo Ohgaki | Date: | Tue, 03 May 2016 23:21:55 +0000 |
| Subject: | Re: ImageMagick vulnerability | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93058@lists.php.net to get a copy of this message | ||
Hi Dan,
On Wed, May 4, 2016 at 7:33 AM, Dan Ackroyd <danack@basereality.com> wrote:
> Sorry for being off-topic, but as the maintainer for the Imagick
> extension I feel it necessary to do my best impression of Paul Revere*
> and warn people of an alleged vulnerability in the underlying
> ImageMagick library.
Not at all.
Thank you for letting us know!
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
>
> Apparently servers that use ImageMagick to process any user uploaded
> images are vulnerable to a remote code execution attack. Ways to
> mitigate this vulnerability are at: https://imagetragick.com/
> which
> include:
>
> #######
>
> Verify that all image files begin with the expected "magic bytes"
> corresponding to the image file types you support before sending them
> to ImageMagick for processing.
>
> Use a policy file to disable the vulnerable ImageMagick coders. The
> global policy for ImageMagick is usually found in “/etc/ImageMagick”.
> The below policy.xml example will disable the coders EPHEMERAL, URL,
> MVG, and MSL.
>
> <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" />
> </policymap>
>
> #######
>
> I believe restarting any PHP process that would have loaded the
> Imagick extension is required to ensure this mitigation takes effect.
>
> For the record, I do not know any more details about the
> vulnerability. Nor do I believe there are any mitigation step that
> could or should be taken in the Imagick extension code.
>
> As an aside, I do recommend only processing images in a locked down
> 'background worker' process, rather directly in the web server; I'm
> not sure if that would help in for this particular vulnerability, but
> it is usually a good idea.