Researchers have disclosed a critical vulnerability in the latest version of Mac OS X that they say Apple has sat on for almost seven months without fixing. The buffer overflow flaw could be exploited by attackers to remotely execute malicious code, and virtually all Apple devices - including Mac computers and servers, iPhones, …
Forgive me but..
"It is true that the examples presented in the previous notes, using the
printf (1) do not work under MacOS X. This does not mean the MacOSX C
library is safe."
"Please note that the issue can also exist in Sony PlayStation 3."
Now I'm all for security being brought forward, but from what I gather its not entirely Apples fault here?
"Not entirely Apple's fault?"
Apple may not have written the buggy code, but they do deploy it. They were told where the issue is, and in there are open source apps that have issued fixes. (You can go crib the code if you can't write your own fix.)
How is it not Apple's fault?
That is correct.
its not about assigning blame, its about fixing bugs
"Now I'm all for security being brought forward, but from what I gather its not entirely Apples fault here?"
Apparently, there's a bug in libc, and its part of the BSD libc, which is distributed by all those platforms.
The problem is that Apple is taking their good time in getting around to release a patch in the library they distribute - a patch which is apparently easy to implement, only they can do it, and would fix a security issue.
Well, yes, and no.
Of course it is not *only* Apple's fault. Sony has sucked eggs here too. But Apple has orders of magnitude more systems in active use in many more sectors than Sony PS3s. And Apple lives on a high-horse of perceived invincibility, while Sony sells rootkits on their own CDs. So, in this case, Apple gets the kneecapping they have well and truly earned. Well done, Vulture Central.
Oh, before people go bonkers and call me a Wintard or something like that, I have been using Macs for over 25 years, and am writing this on my Mini. They're nice computers; Apple makes good products, mostly; but Apple can fail along with any other company and this is a beautiful example.
Tux, because Puffy The Buffer Slayer is not an available icon option.
What has fault got to do with it? They have a responsibility as the distributor to timely patch security vulnerabilities. Is this the 'they still rock cos the bugs are only in someone else's code' defence? Sorry - no defence. Send us a patch!!
Aha! What this means is that Apple want to USE the vulnerability for CONTROL!!
Apple's problem ...
All of their their eggs are in the one basket called "OSX", regardless of hardware.
In Apple's case, the same fix has to work equally across all of the platforms where they use the code. The testing is tricky ... and one of the current reasons that I don't use Apple gear in production environments.
Gotta love the arrogance.
From securityreasons own website, which may I add integrates google adds like it is their own content and thus make people click on the links...Very odd for a security firm...
Anyway don't they admit their examples don't work on their own website, but then state that that doesn't mean OSX is safe...So how about posting an example that actually works and demonstrates this vulnerability on what it does...
I can't get my machine to crash....
And how many times has this bug been exploited in the wild? ZERO.
Get a clue people and look up "Proof of concept"
Good luck remotely hacking any Mac! hahah
Poor Windoze zealots.
I don't believe it. The commentards here told me so. The iPhone is only vulnerable if you have uncrippled it (for example to use bluetooth or run a different music app).
Forcing users to only run apps from Apple's store makes the phone invincible.
Is this real ? ..
I'm curious if The Register team has taken time to validate this claim. I reviewed the details of this vulnerability on their website and out of curiosity I compiled and ran some of the example codes posted on their site and I can't seem to reproduce it.
Is it possible that Apple has patched the problem but never bothered to follow up with these folks to close the loop?
Websites on OSX?
"the vulnerability could be remotely exploited using booby-trapped PHP code on a website"
I'm all in agreement with people saying Apple should have fixed it by now, but the comparison against Unix is not an argument to bash Apple.
For every 1 OSX server running a public-facing website, there's probably 100,000 Unix servers. This was disclosed in June, yet it's the first I've heard of it, so I wonder if it's actually been exploited in the wild?
For every 1
You mean, for THE one OSX server running a public facing web site, right?
"the same fix has to work equally across all of the platforms where they use the code".
True, but they have a VERY limited hardware range to test against, compare that to MS & the Linux community who have to support 100's of thousands of potential configs, how it may affect things such as a AMD Processor, on a Gigabyte board, with a IDE DVD drive, SATA HDD, NVidea Graphics, Creative Sound. Oh did I mention that's 3 year old kit, not just last months.
So relativly, it's easy for Apple.
"So relativly, it's easy for Apple."
I agree! However, as I'm sure you know, Apple is a trifle more thorough than MS when it comes to PQC ... Note that I'm personally appalled that Apple hasn't fixed this yet, and if you re-read mine, I refuse to use Apple kit in production environments. There are reasons for that.
If all Mac people (and Windows people, and Linux people) took your attitude, then this industry would be a nicer place. Also, the average IQ would jump by 30 points!
@ Poor Coco
"But Apple has orders of magnitude more systems in active use in many more sectors than Sony PS3s."
More sectors maybe but more systems running OSX than PS3's out there, are you sure???
If this was Microsoft
Can you imagine how many people would be bashing them right now (especially the Fanbois)......
Well, my Macbook (Snow Leopard latest patches) doesn't crash when I test out this bug - it does crash the process that's in context though.
Your standard buffer-overflow exploit then, and nothing worth getting all fanny-flapping about.
Nevertheless...this is libc we're talking about...
Apple shows a great deal of disrespect to the libc, and by extension all c programmers by still ignoring this.
I don't know what Apple is doing
I'm waiting for Apple to fix the firewire interface which they broke in 10.6
Based on my reading of the article...
The security firm found this exploit 7 months ago then contacted Apple (and the other affected comapnies) and has since sat on it and not released details in order to give the companies time to patch their systems. Most of those have. Apple has not.
Now in order to try and force Apple to fix the security hole, the security firm are releasing a script which (based on peoples comments here) doesnt entirely work but should be close enough that someone with insider knowledge of the system could get it to work, but it would probably take time and hopefully Apple will now use that time to plug the gap. This seems like a particularaly responsible way to go about it to me.
Still if Apple continues to do nothing, i kinda hope (and i apologise to Apple users in advance) that this security hole does get exploited so that it embarrases the hell out of Apple and makes them get around to fixing the issue. Just because no one has taken advantage of a security hole and even if that security hole is very difficult to penetrate there is no excuse for not plugging it when it appears to be a (relatively) simple fix...
is currently being finalised. I'd expect that this will be fixed. http://arstechnica.com/apple/news/2010/01/apple-moves-to-improve-opengl-support-in-1063-builds.ars
- Apple stuns world with rare SEVEN-way split: What does that mean?
- Special report Reg probe bombshell: How we HACKED mobile voicemail without a PIN
- RIP net neutrality? FCC boss mulls 'two-speed internet'
- Sony Xperia Z2: 4K vid, great audio, waterproof ... Oh, and you can make a phone call
- Pic Tooled-up Ryobi girl takes nine-inch grinder to Asus beach babe