1. 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

Discussion in 'Server Configuration and Hosting' started by thedude, May 3, 2016.

  1. thedude

    thedude Well-Known Member

    "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:
    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.
     
  2. Chris D

    Chris D XenForo Developer Staff Member

    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.
     
    Divvens, Mouth, eva2000 and 1 other person like this.
  3. thedude

    thedude Well-Known Member

    Good to know (y)
     
  4. eva2000

    eva2000 Well-Known Member

    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
     
    SneakyDave and thedude like this.
  5. Fred.

    Fred. Well-Known Member

    I just have
    Code:
    Path: [built-in]
      Policy: Undefined
        rights: None
    It says rights none, I would think it's ok then? Or not?
     
  6. Tracy Perry

    Tracy Perry Well-Known Member

    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.
     
    eva2000, thedude and Fred. like this.
  7. Fred.

    Fred. Well-Known Member

  8. eva2000

    eva2000 Well-Known Member

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

    Tom_ Member

    Anything new about this?
     
  10. Chris D

    Chris D XenForo Developer Staff Member

    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).
     
    Divvens and eva2000 like this.
  11. eva2000

    eva2000 Well-Known Member

    Last edited: May 6, 2016
    Chris D likes this.
  12. Digital Doctor

    Digital Doctor Well-Known Member

  13. Chris D

    Chris D XenForo Developer Staff Member

  14. Chris D

    Chris D XenForo Developer Staff Member

    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!
     
    MattW, ManagerJosh, Fred. and 5 others like this.
  15. Tracy Perry

    Tracy Perry Well-Known Member

    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.
     
    thedude, Fred. and SneakyDave like this.
  16. motowebmaster

    motowebmaster Active Member

    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.
     
  17. Tracy Perry

    Tracy Perry Well-Known Member

    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.
     

Share This Page