STE WILLIAMS

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.

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. (A fix has been promised for the weekend starting 2016-04-23.)
• 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.

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/a-OC16aZZLc/