Recommended + Security & Privacy + Security News

Apple Criticised for Not Patching OS X Yosemite Zero-Day Vulnerability

Posted on July 22nd, 2015 by

OS X Yosemite vulnerability

A German security researcher, Stefan Esser, has published details of a zero-day vulnerability in OS X that could allow a malicious hacker to escalate their privileges, opening opportunities for them to hijack complete control of innocent users' Macs.

And despite releasing the details of this latest OS X security hole without informing Apple beforehand, Esser seems to have no regrets.

To be nerdy for a second, the security flaw appears to lie in new features introduced in OS X Yosemite and the upcoming OS X El Capitan, and relate to how Apple altered its dynamic linker code in OS X 10.10 to support the new DYLD_PRINT_TO_FILE environment variable.

Whilst not considered as critical as remote code execution vulnerabilities, privilege escalation bugs are still serious — a malicious hacker who has already broken into a computer system can use the exploit to give themselves system-level powers.

Esser published full details of the security hole, including proof-of-concept exploit code, on his blog.

The proof-of-concept code Esser has published is, he warns, dangerous because it installs a root shell onto Mac computers. For understandable reasons, we won't link directly to it from this article.

Proof of concept code

Stefan Esser works for security audit firm SektionEins, and has previously found numerous software vulnerabilities, as well as analysing the so-called "UnFlod Baby Panda" malware that targeted jailbroken iPhones and iPads.

Frosty Apple

But what has really helped give Stefan Esser — also known as i0n1c — a name for himself are the flaws he has found in Apple's software, and his low opinion of the quality of Apple security.

I think it would be fair to say that Apple and Esser have a frosty relationship.

Just take a glance at the posts Esser made on his his Twitter account after he announced the flaw if you don't believe me:

"Imagine how much money one could make if Apple cared about security and paid bug bounties..."

"No need to smoke pipes to get root on OS X"

"Same exploit should work btw on *jailbroken* iOS 8 iPhones to get root from mobile user."

"Of course there are the usual comments like: "why didn't you contact Apple?" - feel free to work for free and do it yourself."

Esser's full disclosure certainly isn't popular with everyone, including participants in a Reddit thread about his publishing of the flaw.

Take this response, for instance, from Reddit's yepthatguy2:

It's not about Apple. It's about people who happen to use Apple's products. The publication of this vulnerability doesn't hurt Apple (much). It mostly just hurts users.

And if your answer is "That's your fault for using Apple's products", then please direct me to the computer system that has zero security holes.

Meanwhile, back on Twitter, Esser proved himself to be unrepentant when quizzed about why he hadn't emailed Apple's security team about the flaw:

Twitter exchange

El CapitanBut what has really got the security researcher's goat is the discovery that the beta version of Apple's upcoming version of OS X, El Capitan, does *not* have the same bug.

In Esser's view, this is a sign of the company's irresponsible behaviour — working on a vulnerability fix that was shipped with the El Capitan beta in June, but apparently not bothering to backport it for the latest official version of OS X.

So Apple was informed about said bug months ago and as usual did the irresponsible to fix it for some beta half a year in the future only.

Apple is indeed worse than Adobe.

So Apple has working fix + released it in June with El Capitan beta, but did not backport. Has intention to fix in September.

To mitigate the threat, Esser's firm SektionEins has released a kernel extension that protects computers by "stopping all DYLD_ environment variables form being recognized by the dynamic linker for SUID root binaries."

The source code of that tool can be downloaded from GitHub.

I guess we should be grateful that, at the very least, an unofficial fix has been in released alongside details of how to exploit the flaw — but it's clear that the vast majority of Mac users will not use it.

Let's all hope that Apple responds appropriately, with a security update for all affected OS X users. And yes, I mean those of us using the latest version of OS X Yosemite.

Was Stefan Esser and his company SektionEins right to publish details of the vulnerability without informing Apple privately first? Would a co-ordinated disclosure of the flaw have been safer for the Apple community? Or is Esser performing a valuable service that keeps Apple's engineers on their toes?

Leave a comment with your point of view below.

About Graham Cluley

Graham Cluley is an award-winning security blogger, researcher and public speaker. He has been working in the computer security industry since the early 1990s, having been employed by companies such as Sophos, McAfee and Dr Solomon's. He has given talks about computer security for some of the world's largest companies, worked with law enforcement agencies on investigations into hacking groups, and regularly appears on TV and radio explaining computer security threats. Graham Cluley was inducted into the InfoSecurity Europe Hall of Fame in 2011, and was given an honorary mention in the "10 Greatest Britons in IT History" for his contribution as a leading authority in internet security. Follow him on Twitter at @gcluley. View all posts by Graham Cluley →
  • Coyote

    Well I’ll be blunt: it is a marketing ploy. Look at his website and you see the following:

    “Before I share a working POC exploit for this problem with you, let me
    finish this post by highlighting that SektionEins is organizing several
    OS X and iOS related trainings later this year. If you enjoyed this blog
    post then especially the OS X and iOS Kernel Internals for Security Researchers Training* in October should be of interest for you.”

    The fact he gives a kernel modification that will mitigate (or attempt to) the problem is worse; he states that it would take a long time for Apple to fix the problem (yet he hasn’t contacted them? how would he know?) so instead he’ll be helpful by giving a fix (while promoting his organisation). No, this is rather shifting the focus away from the reality (wanting business). An effective tactic, admittedly, but it isn’t hard to sniff out, either. He would be a good politician (nothing to be proud of).

    It would be rather silly to offer a fix when he hasn’t bothered to contact Apple; surely Apple would want to fix it? (Whether they always do or not is another issue entirely and one I will not even attempt to discuss) But he isn’t doing it out of good but out of selfishness (and shameless promotion of his organisation). That is the problem here: it is to get customers (or followers if nothing else), attention and not much else.

    Irresponsible? I think that isn’t the word I’d use. I’m not sure there is a very good word. It is a somewhat sneaky way of advertising his training course(s). It is pathetic, actually.

  • Junk EB

    Absolutely irresponsible in the worst way. Petulant guy with a beef decides to release working code for a major flaw without making the vendor aware first. Sounds like the kind of guy to leave a loaded firearm in a kids playground then decry the parents when one gets shot.

  • SN33R

    I don’t know why a company of such magnitude wouldn’t offer bug bounties. There are many other less savoury types who would be happy to pay for this information.

  • http://www.SeanDurrant.Co.UK/ Sean Durrant

    Another Nail in the Coffin of the all Macs are impervious to Malware, Viruses and Ransomware theory.

  • Vito Tuxedo

    Of course it was irresponsible to publish details of the vulnerability without contacting Apple. It potentially harms users of all versions of OS X that have the same vulnerability.

    There’s no question that the information about the vulnerability would have been useful to Apple…IF they didn’t already know about it. But if I understand the article correctly, Apple DID already know about it, because they had already patched it in the most recent beta of El Capitan.

    On that basis, Mr. Esser didn’t tell Apple anything they didn’t already know, so the suggestion that he might have provided “a valuable service” to Apple’s engineers doesn’t hold water.

    Notwithstanding the irresponsibility of Mr. Esser’s actions, I fully agree with his point that Apple is acting irresponsibly by patching the El Capitan beta but NOT issuing a corresponding patch for the installed versions of Yosemite.

  • freedonuts

    This bug is not just a typical security flow. It’s NEW code that was only recently added to the heart of the OSX system. The way this new feature was added shows a massive people problem on Apple’s side. The person that added this code expressed zero know-how of the security sensitive area he was working in. It also unveils that Apple totally lacked proper code reviews at the time this was implemented. The best ways to help get this all fixed is not by keeping al this under the carpet but by creating a massive shitstorm that forces the responsible Apple managers to take action. If it was just some obscure bug, the situation might be different. In this case, it’s not a bug. It’s negligence by the team responsible for the core OS. Real scary..

    • Coyote

      As an aside: I hate Microsoft and I hate Apple, so this isn’t me
      defending them out of bias. I’m not defending them at all, actually; I’m being realistic and fair.

      Actually, if you understand even basic Unix (Mac OS is based on NeXT and one or more of the BSD Unix OSes) system programming (with a little emphasis on security in this case), you would see that this is a bug. For that matter, it doesn’t matter what the cause of the bug is; it is still a bug. You do know how the term debugging was popularised, right? If not and you really want to be enlightened (hint: a moth) look up Grace Hopper. Also, if you look back at the Heartbleed bug, and again you understand basic programming (in that case basic programming regardless of what environment), it WAS pure negligence (he didn’t check for space in a buffer or buffers, as I recall – an amateur mistake). But it was still a bug.

      As for how to get it fixed. You’re right in a sense – you can’t fix it if you don’t know about it and also don’t find it by accident or go looking for it – but there are different ways of approaching it (there is a reason bugzilla and similar bug reporting/feature requests/etc. methods exists; whether Apple has bugzilla or not isn’t my point here). Finally, all the code auditing in the world won’t find 100% of the bugs 100% of the time (and new bugs will occur). That is something that any real programmer would know; perhaps only programmers know it but it is still a fact.

      • freedonuts

        I did my share of creating bugs so yes, I’m aware of the concept. If you like to classify every bug as just a bug, fine with me. I typically like to look at bit further at what might have caused (me) to create a specific bug. Usually, that’s where the learnings and process improvements take place. Looking at the code of this specific bug my option is pretty strong that it’s very likely a lack of security awareness on whoever decided to have this code added in this specific way. That clearly doesn’t make it less of a bug so yes, in that sense, I agree with everything you write. I can’t be found if the intention was to implement it exactly the way it was done. That’s the part were it becomes really, really scary..

        • Coyote

          After writing the below (I’m on the same page as you, fwiw), I think the problem is I am a very literal thinker, and so when I saw:

          “In this case, it’s not a bug. It’s negligence by the team responsible for the core OS. Real scary..”

          I interpreted it as it isn’t a bug, full stop. But I see what you mean now. Yes, it is scary, and yes I agree with you: it is lack of awareness; that is the problem with security (and most other things in this damned world), isn’t it? It is a huge problem because if you aren’t aware of your lack of awareness (and/or ignorance) then how can you address it? But it is still a bug – the source (hope you don’t mind puns … as it isn’t the first and it won’t be the last) of the problem is of course something that is necessary to understand if you’re the programmer (or the one fixing it) BUT it is still a bug, no matter what caused it.

          Mind you, from years of experience and always improving on this, I’ll say it straight out: debugging isn’t a science; it is art. Indeed if you learn how bugs arise (even the kinds that have wings), and if you have the right mindset (and/or intuition), it is almost like you know exactly what caused the bug and how to solve it (and how to track it down). I’ve experienced this a lot. Lastly, on that subject, indeed bugs aren’t just added by accident, they are created (I prefer the word implemented) and that implies that they will always be abound. But agreed, the mistakes here were serious. Thing is, if you can’t teach security in full (in that it also involves aptitude), then how can you teach secure programming (as it is, programming courses to the masses also has problems because of aptitude and other things)? That is also scary. Think of this scary mentality, and something that I don’t think teachers of programming properly teach (certainly not enough[1]): since no user in their right mind would input more than 100 characters, then an array of 250 will suffice. And if I ever expect more input, I can just add to the buffer size; no need for dynamic allocation! Except of course that is all wrong.

          [1] Of course, with higher level languages, this is less of a problem for some things (e.g. C++ has the std::string type that grows as the need arises), but the fact is too many (>0) don’t check the bounds of arrays (etc.) before reading/writing to them (see Heartbleed).

          Cheers.

  • Gregor Pogačnik

    Giving the bug to Apple for free would be irresponsible because it would just continue the status quo. “Invest into infosec or proper testing? Why? People will tell us about flaws anyway”. There should at least be some symbolic bug bounty to compensate for researchers’ time.

    Don’t get me wrong, nice find. But the thing was basically dead so all the zombie was good for was some PR stunt. Before ElCapitan the thing was worth more and I highly doubt i0n1c would share details about it.

    However afaik SUIDguard was released _before_ the details which is quite responsible. At least when you compare that to silently patching a security issue in a new OS release. Of course unless Apple wasn’t aware of the implications. But that scenario is probably even worse…