ImageMagick remote code execution (RCE) vulnerability

[thedude]

"There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild."

This will apparently be fixed in ImageMagick versions 7.0.1-1 and 6.9.3-10

ImageMagick's own forum discussion
ImageTragick vulnerability page
Hacker News discussion

To fix this issue on affected versions (older than 7.0.1-1 and 6.9.3-10):

1. SSH into your servers.

2. Type in

convert -list policy

What you want to see are the items in bold:

Path: <some-path>/policy.xml
Policy: Unrecognized
rights: None
Policy: Coder
rights: None
pattern: EPHEMERAL
Policy: Coder
rights: None
pattern: HTTPS
Policy: Coder
rights: None
pattern: MVG
Policy: Coder
rights: None
pattern: MSL
Policy: Coder
rights: None
pattern: URL

If you don't see the see the bolded items in your output, then here's how we fix it.

Use your favorite editor (nano, pico, vim, vi, etc) to edit the file that was listed in the "Path:" parameter of the output above. So if your Path parameter showed Path: /etc/ImageMagick-6/policy.xml, you would open the file /etc/ImageMagick-6/policy.xml in your favorite editor.

Once opened, scroll to the end of that file and find the closing of the policymap section. It'll be indicated by the following (notice the right leaning slash):

</policymap>

Insert the following directly above the closing policymap tag you found above:

  <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="URL" />

So with the closing tag included, it should look like this:

  <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="URL" />
</policymap>

Save and exit the file.

Re-run the command in step 2 at the top of this post and verify that you're seeing the necessary policies in your output from that command.

 

[Chris D]

We've been looking into this.

Certainly the fix suggested here is worth implementing, regardless, but we are currently investigating whether it's actually exploitable through XF and XFMG.

Reason being we run all images through getimagesize() which should handle the magic byte detection, which is another safe guard against this issue - essentially verifying that the image provided is a valid image.

 

[thedude]

we run all images through getimagesize() which should handle the magic byte detection, which is another safe guard against this issue - essentially verifying that the image provided is a valid image.

Good to know

 

[eva2000]

All taken care of now https://community.centminmod.com/posts/30693/

php --ri imagick

imagick

imagick module => enabled
imagick module version => 3.4.2
imagick classes => Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator, ImagickKernel
Imagick compiled with ImageMagick version => ImageMagick 6.9.3-10 Q16 x86_64 2016-05-04 http://www.imagemagick.org
Imagick using ImageMagick library version => ImageMagick 6.9.3-10 Q16 x86_64 2016-05-04 http://www.imagemagick.org
ImageMagick copyright => Copyright (C) 1999-2016 ImageMagick Studio LLC
ImageMagick release date => 2016-05-04
ImageMagick number of supported formats:  => 225
ImageMagick supported formats => 3FR, AAI, AI, ART, ARW, AVI, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FITS, FRACTAL, FTS, G3, GIF, GIF87, GRADIENT, GRAY, GROUP4, GV, H, HALD, HDR, HISTOGRAM, HRZ, HTM, HTML, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, JBG, JBIG, JNG, JNX, JPE, JPEG, JPG, JPS, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPEG, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIFF, VIPS, VST, WBMP, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV

Directive => Local Value => Master Value
imagick.locale_fix => 0 => 0
imagick.skip_version_check => 0 => 0
imagick.progress_monitor => 0 => 0

 

[Fred.]

I just have

Path: [built-in]
  Policy: Undefined
    rights: None

It says rights none, I would think it's ok then? Or not?

 

[TPerry]

I just have

Path: [built-in]
  Policy: Undefined
    rights: None

It says rights none, I would think it's ok then? Or not?

Not... that's the default.
Simply edit the XML file and add the policy map entries in... or if you are using CentMin Mod (the BETA version) just choose option 15 from the menu.

 

[Fred.]

Thanks for the confirmation @Tracy Perry

I'm safe now.

 

[eva2000]

or if you are using CentMin Mod (the BETA version) just choose option 15 from the menu.

For Centmin Mod LEMP stack users I have also posted official site and forum announcements for this as well.

 

[Tom_]

We've been looking into this.

Certainly the fix suggested here is worth implementing, regardless, but we are currently investigating whether it's actually exploitable through XF and XFMG.

Reason being we run all images through getimagesize() which should handle the magic byte detection, which is another safe guard against this issue - essentially verifying that the image provided is a valid image.

Anything new about this?

 

[Chris D]

Regardless of whether XF allows this to be exploitable, the recommendation is to have Image Magick upgraded or implement the workarounds as advised by them.

I haven't yet seen a proof of concept for the exploit, so we cannot confirm with any accuracy whether it is exploitable.

We suspect it isn't because we pass all images through the getimagesize function which should assert the image is valid.

I will look into it again to see if there is an example (it has been a few days since l checked).

 

[eva2000]

I haven't yet seen a proof of concept for the exploit, so we cannot confirm with any accuracy whether it is exploitable.

site at has been updated with examples at https://imagetragick.com/ as has http://www.openwall.com/lists/oss-security/2016/05/03/18

and https://github.com/ImageTragick/PoCs

 

[Digital Doctor]

at https://imagetragick.com/

haha.
interesting read.

 

[Chris D]

site at has been updated with examples at https://imagetragick.com/ as has http://www.openwall.com/lists/oss-security/2016/05/03/18

and https://github.com/ImageTragick/PoCs

Great - last time I checked this hadn't been updated yet. Thanks.

 

[Chris D]

None of the example "images" in those PoCs actually can be uploaded because they are not actually image files and therefore not accepted as such. This confirms our theory that XF is protected due to the "magic byte" detection, which is essentially what the getimagesize() function does.

That said, regardless -- please update ImageMagick anyway!

 

[TPerry]

Think the new recommendation for the policy.xml is

  <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" />
  <policy domain="coder" rights="none" pattern="TEXT" />
  <policy domain="coder" rights="none" pattern="SHOW" />
  <policy domain="coder" rights="none" pattern="WIN" />
  <policy domain="coder" rights="none" pattern="PLT" />

for those that cannot upgrade to the latest version.

 

[motowebmaster]

I removed ImageMagick completely, went back to GD, not a happy camper What is strange though is that my site now seems to be running faster

Still a believer, but will spin-up a test server on D.O. and do some trial-n-error with what is available direct from the ImageMagick site before making another attempt on the production server.

 

[TPerry]

What is strange though is that my site now seems to be running faster

Not totally unexpected.. pretty sure that ImageMagick has a few more abilities than GD does for image processing so it's probably a "heavier" load.