Slashdot Mirror
Huge Number Of Sites Imperiled By Critical Image-Processing Vulnerability (arstechnica.com)
Dan Goodin, reporting for Ars Technica: A large number of websites are vulnerable to a simple attack that allows hackers to execute malicious code hidden inside booby-trapped images. The vulnerability resides in ImageMagick, a widely used image-processing library that's supported by PHP, Ruby, NodeJS, Python, and about a dozen other languages. Many social media and blogging sites, as well as a large number of content management systems, directly or indirectly rely on ImageMagick-based processing so they can resize images uploaded by end users. According to developer and security researcher Ryan Huber, ImageMagick suffers from a vulnerability that allows malformed images to force a Web server to execute code of an attacker's choosing. Websites that use ImageMagick and allow users to upload images are at risk of attacks that could completely compromise their security. "The exploit is trivial, so we expect it to be available within hours of this post," Huber wrote in a blog post. He went on to say: "We have collectively determined that these vulnerabilities are available to individuals other than the person(s) who discovered them. An unknowable number of people having access to these vulnerabilities makes this a critical issue for everyone using this software."
Suggestion: read the article and details, before making assumptions. Because if you did, you would have see that that was done. A patch was created but apparently not complete. They also include two mitigation 'patches' (config) in the disclosure. Considering the seriousness of this exploit (even I could understand it - which makes it beyond trivial) the more attention this gets, the better.
From https://imagetragick.com/
April, 21 2016 - file read vulnerability report for one of My.Com services from https://hackerone.com/stewie received by Mail.Ru Security Team. Issue is reportedly known to ImageMagic team.
April, 21 2016 - file read vulnerability patched by My.Com development team
April, 28 2016 - code execution vulnerability in ImageMagick was found by Nikolay Ermishkin from Mail.Ru Security Team while researching original report
April, 30 2016 - code execution vulnerability reported to ImageMagick development team
April, 30 2016 - code execution vulnerability fixed by ImageMagick (incomplete fix)
April, 30 2016 - fixed ImageMagic version 6.9.3-9 published (incomplete fix)
May, 1 2016 - ImageMagic informed of the fix bypass
May, 2 2016 - limited disclosure to 'distros' mailing list
May, 3 2016 - public disclosure at https://imagetragick.com/
This bug has nothing to do with the language it's written in. It's a simple matter of failing to properly escape special characters when switching contexts (filename -> executable command). You can mess that up in any language.
Update your /etc/ImageMagick/policy.xml file so that it contains this (taken from http://imagetragick.com ) and restart corresponding daemons:
/> /> /> /> /> /> /> /> />
<policymap>
<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"
</policymap>
You're safe now. The full fix is still being worked out.
What, in your opinion should the upload receiving routines check? In the example, the website would resize profile photos that users upload. One image format would have the possibly to "include" contents that is to be downloaded from someplace else. Imagemagick performs such downloads by handing off that task to wget (or similar tool), which it calls via system(), completely forgetting to santize the URL (... so somebody might append "; rm -rf / to it, or somesuch). How do you propose that the upload routine of the web site catch this, short of parsing the entire image itself? But if it did that, there'd be no point of using an image processing tool at all, because the wrapper would already half done two thirds of the job.
Strictly speaking, those two aren't equivalent. The C example is using dynamic memory with runtime sizing, while the C++ one is using static sizing (and that array would be allocated on the stack). std::vector p would be the C equivalent. Other than that, I agree with you. Pretty much the only reason to use C these days is if your platform doesn't have a good C++ compiler.
Turns out we should have been using the better fork since 2002 anyway.