ImageMagick is free, open source image processing software that’s been around for more than 25 years.
You may never have heard of it, or seen its logo, a friendly-looking wizard with a binary-encrusted hat, a long white beard and an image-tweaking wand.
But there’s a good chance that you’ve used ImageMagick without even realising it, for example when you’ve uploaded images to a website or a blogging service for later use on web pages or in articles.
ImageMagick isn’t like GIMP, or Adobe Photoshop, or Apple’s Photo app, where you open up an image in a graphical window and then work on it interactively with a range of design tools from a menu.
ImageMagick is a set of command-line programs that’s ideal for the bulk processing of images in a repeatable way.
For example, if you offered an online service where users could store their latest holiday snapshots and then browse them later, you might use ImageMagick to produce a set of image thumbnails automatically.
You could run a batch job to crop all the uploads so they were square, scale them all to exactly 200×200 pixels, and then convert them to 256-colour GIF files with a standard palette.
You can even use ImageMagick to add text annotations to your images, for example by adding a grey bar across the bottom with a copyright notice written in; to perform automatic colour correction; to sharpen the focus of a batch of images; to produce animated GIFs for websites; and much more.
ImageMagick also supports various scripting languages of its own, such as MSL (Magick Scripting Language) and MVG (Magick Vector Graphics), that let you describe images, in both pixel-based and vector-based formats, as a sequence of text commands.
What this means
What this means is that ImageMagick often runs in the background on internet-facing servers, automatically processing untrusted images that are uploaded by remote users.
Unfortunately, a vulnerability in ImageMagick reported today (CVE-2016–3714) allows booby-trapped image uploads to trick the ImageMagick software into running commands instead, leading to what’s known as a remote code execution (RCE) bug.
According to one report, cybercrooks already know about this and are exploiting it in the wild.
As you can imagine, crooks love server-based RCE holes because those holes allow them to take over legitimate websites, mostly running some flavour of Linux, and use them for criminal purposes such as phishing, data theft, and ransomware distribution.
LISTEN NOW
(Audio player not working? Download MP3, listen on Soundcloud, or read the transcript.)
What to do?
- If you have a hosted website or blog, ask your hosting provider if they use ImageMagick.
- Patch ImageMagick as soon as possible. (Update. A fix was promised for the weekend of 2016-05-07; it was delivered by 2016-05-03, shortly after this article appeared.)
- In the meantime, apply ImageMagick’s suggested workaround by editing ImageMagick’s policy.xml file.
Details of the vulnerability have not yet been disclosed in order reduce the risk of copycat exploits.
However, the ImageMagick workaround involves adding the following lines to the product’s policy configuration:
<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" />
Simply put, these lines turn off automatic processing of certain types of input, none of which are traditional image files such as JPEG or GIF, and all of which can be used to refer to files on the local filing system.
We’re guessing that this ability to refer to “inside” files from outside the network is part of the problem that makes remote code execution possible.
As it happens, advice in one of ImageMagick’s support forums has been suggesting these locked-down settings since 2014, but they’re not yet part of the policy.xml file by default.
Interestingly, a third-party information site calling itself ImageTragick (yes, this bug has already attracted a logo, a PR-friendly name and a web page) also recommends adding:
<policy domain="coder" rights="none" pattern="URL" />
Presumably, that additional line turns off ImageMagick’s processing of remotely-specified URLs even if they aren’t using HTTPS.
Unless I missed the memo on the possibility of time travel, how can a fix be announced for a weekend that has already passed? I gather from the post that a fix will be there on the weekend of April 23rd. Or, being European, I totally misread the date of the promised fix.
Errr, that was a special sort of time travel called “a typing mistake.” Sorry about that.
I edited the article to say that the weekend in question was 2016-05-07. Happily, the fix was happily published much sooner than promised – not long after this article was published, it seems. (The mention of “fix coming by the weekend” has been removed from the vulnerability notice linked to above.)
HtH.
Thanks Paul – calling GoDaddy now mate.