Re: ImageMagick vulnerability

From: 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.

« previous php.internals (#93058) next »