• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

ImageMagick remote code execution (RCE) vulnerability

thedude

Well-known member
#1
"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
Code:
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):
Code:
</policymap>
Insert the following directly above the closing policymap tag you found above:
Code:
  <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:
Code:
  <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

XenForo developer
Staff member
#2
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.
 

eva2000

Well-known member
#4
All taken care of now https://community.centminmod.com/posts/30693/ :)
Code:
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.

Well-known member
#5
I just have
Code:
Path: [built-in]
  Policy: Undefined
    rights: None
It says rights none, I would think it's ok then? Or not?
 
#9
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

XenForo developer
Staff member
#10
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).
 

Chris D

XenForo developer
Staff member
#14
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!
 

Tracy Perry

Well-known member
#15
Think the new recommendation for the policy.xml is
Code:
  <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.
 
#16
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 (y)

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.