3

Can someone who really knows what they're looking at advise whether the patch published here by Stefan Esser is in fact safe to install?

While I'm very concerned that Apple haven't published an official patch yet (especially now that I've tried Esser's example myself), this is a kernel extension so I'm equally hesitant to just rush into implementing it.

Note: I'm grateful to Esser for drawing attention to this and am not implying his fix might by 'malicious' (particularly as it's openly published). I just want an informed answer on exactly how it works and whether there are any side-effects.

4
  • This may be the wrong site for this type of question. Perhaps serverfault.com would be better? Jul 23, 2015 at 13:00
  • @"Neil Smithline": Isn't the core of this question a risk evaluation question? Do you think colleagues on this group are unqualified to analyze code security?
    – dan
    Jul 23, 2015 at 13:13
  • @NeilSmithline this directly impacts the security of any computer running OS X 10.10.X - that includes MacBooks, iMacs etc etc
    – toxefa
    Jul 23, 2015 at 13:18
  • Alright. Works for me. Jul 23, 2015 at 13:20

1 Answer 1

2

The first important thing is to think about the meaning of this security hole. This is a local privilege escalation: if an attacker can get to run code of his choosing on the machine, with "normal" privileges, then that attacker can use this hole to obtain more extended privileges on that machine.

In general, for a desktop system, when attackers can run their own code on your machine, they have already won. On a desktop systems, your own actions, as a "normal user", are all done as process running, from the point of view of the kernel, with the privileges attached to your user account. If an attacker manages to run his own code, it will be through subverting one of your applications, or making you unwittingly run a seemingly honest screensaver or something like that. Privileges attached to your account are sufficient to plunder the contents of all your files, display spurious ads, hijack your network connections, and generally steal your whole life. Also obtaining root privileges on the machine does not substantially increase the scope of the disaster, though it may make life easier for the attacker.

Moreover, as a "normal user", you already have ways to obtain root privileges, and you do use them on a regular basis -- e.g. to authorize an update of the Flash plugin. The updater system will ask you for your password and use it to request and obtain root privileges. An attacker who can run code under your name just has to mimic a Flash update to display the popup and obtain the privileges. In that sense, the new vulnerability is irrelevant for a desktop system. Correspondingly, there is no hurry in fixing it.


Privilege escalation holes make a lot more sense on shared servers, where several users who can potentially be hostile to each other share the same hardware, and the OS must arbitrate between users and protect them from each other. Shared servers are an old model, back when we were talking of mainframes. An information security professional who is now in his forties must have been exposed to that model while he was a student, in the 1980s or 1990s. At that time, computer students were typically using terminals in some shared computer room, and accessing one or a few central servers with a Unix-like operating systems. Privilege escalation was then a much sought after grail.

This rarely applies nowadays. Right now, in 2015, when there is shared hardware, users are granted virtual machines, not simply shell accounts. There still are places where servers are shared in the old way, but they are a vanishing species. If your OS X machines are servers that are used that way, with users that you cannot all trust (or that do not trust each other), then yes, the privilege escalation hole is a big concern. However, chances are that this is not the case.


Assuming that you still want to fix the hole quickly by installing Esser's patch, then you have two points to consider:

  1. You are, basically, inserting in your machine, with "kernel privileges", a piece of code downloaded off the Internet. This entails a rather heavy dose of trust. You must be sure that the Internet persona that appears to go by the name of "Stefan Esser" is trustworthy enough, and that nobody else could alter the patch where it is stored or while you download it.

    How would some "guarantee" by another Internet persona, even with an awesome avatar, create some extra trust ?

    You could, though, get the source code, audit it, then compile it yourself. But if you feel that you can do that, then you do not need any help from a StackExchange site; you already know enough.

  2. The patch changes the behaviour of the machine, conceptually to make it "better" (or "safer"), but a change is always a change and may break things. It is possible that some application developer, somewhere, had noticed that some DYLD_* environment variables survive through SUID execution, and actually used it for some functionality (without necessarily noticing that this has security implications). While the patch appears to be harmless enough (at least from what I see in the source code -- but can you trust me ?), I cannot exclude the possibility that it impacts the behaviour of some parts of the OS or applications.

12
  • Your response is ten paragraphs. Only three of which are relevant (the ones under 1.). In point of fact, the opinion of someone with an awesome avatar on here really does matter and establish trust, if they have a track record of answering questions well (so, we know they're qualified and, more often than not, fail to answer maliciously), and they audit the code. Jul 24, 2015 at 0:36
  • If I can't trust the community on here to give sound security advice and monitor itself, and have multiple people with high rep audit code and reach a consensus, then there sort of isn't a point to the site at all. This site gives security advice. If that wasn't a problem last week, why is it a problem now? Jul 24, 2015 at 0:37
  • I don't deal with trust. I provide information and explanations -- to be used by human brains who like to think. Basing any kind of trust on anything as fuzzy as a semi-anonymous social media, however well-organized, would be quite insane, and was already last week, last month and last year. Jul 24, 2015 at 0:42
  • 2
    Speaking of which, the seven paragraphs that you dismiss so lightly are relevant: a notion of risk is meaningless if you do not know what you would gain through the installation of the patch; and these paragraphs tell you that (and the answer being: about nothing). Jul 24, 2015 at 0:44
  • That's all well and good, but if you audited the code (which, from cursory examination, is only ~100 lines) you could probably give a pretty good explanation of what it's doing and why it makes sense / doesn't make sense to use it. And then, if someone else read the code and disagreed, they could add that in a comment (over which you'd have no control) and the community as a whole could read the conversation, look over the code, and vote accordingly. Jul 24, 2015 at 0:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.