Live data from Hacker News

OS X 10.10.5 kernel local privilege escalation

github.com

91–100 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#91

Earlier quoted context omitted.

I'm not sure if I would ever fully support this kind of disclosure, but maybe we should consider that both this person and Stefan Esser (DYLD_PRINT_TO_FILE) concurrently released fixes/mitigations, meaning vigilant users are secure faster than they would be if it was kept secret until Apple patched it.

Are you talking about his comment about -no_shared_cr3, which causes a noticable performance degradation, and how he will be releasing a kext soon - neither of which is mentioned in the github readme, but buried in HN comments? A small portion of users might be considered vigilant, but they're not psychic. The largest target for local privesc are the people who get hit by different kinds of malware, usually as a payl…

I'm counting on the press and community to distribute the information about the no_shared_cr3 workaround and any kext that comes out, just as Apple's fix is most effective when everyone's being told they should be sure it gets applied.

There are people in this thread more secure today than they were yesterday, and they owe it to this "irresponsible disclosure." Do they have less of a right to security than the "unelite"? We don't know whether this is already being exploited by someone else, and as you said, it could be weeks before an official patch. This release both lights a fire under Apple and helps a few people patch early or at least be extra-careful about what they execute. That's an "upside"... I guess it's down to one's own values and possibly omniscience to conclusively determine whether the downsides outweigh that.

A more responsible version of this might be to release the source of a kext that patches the issue concurrently with confirmation from Apple. Apple got a few hours' head-start, some people can patch early, malware authors will have to spend some time reverse-engineering a complete exploit.

Re: OS X 10.10.5 kernel local privilege escalation

#92

Any way to protect a machine until apple publishes an update?

add -no_shared_cr3 to your boot-args. it will have an hefty performance penalty, but if you value security over performance, it'll also protect you against a lot of (even 0day!) exploits.

Unfortunately this 'fix' seems to break VirtualBox.

Re: OS X 10.10.5 kernel local privilege escalation

#93
post #54

Earlier quoted context omitted.

'sudo nvram boot-args=-no_shared_cr3' will do the trick. The flag essentially prevents kernel from accessing userland memory unless special routines are used. Since the bug is a NULL pointer deference (which requires a read to userland memory in order to be exploited), exploitation becomes impossible. Due to this flag, however, your kernel will have to context switch every time a system call is done, which does have…

Intriguing. Thanks for sharing. Doesn't Linux perform this "context switch at every syscall" ? How does it get away with the performance penalty?

No, Linux x86-64 doesn't change %cr3 on syscalls. It mitigates this kind of bug (kernel NULL pointer dereference) in a different way - by not allowing userspace processes to map memory at NULL.

Linux also supports the SMAP feature on modern Intel CPUs which allows the kernel to set things up so that all accesses to usermode memory from kernel mode must be explicitly annotated.

Re: OS X 10.10.5 kernel local privilege escalation

#94
post #62

Earlier quoted context omitted.

Interesting. I am on 10.10.4 myself, and that's the OS I tested it on. tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. the KASLR leak part is not 100% reliable, unlike the actual code execution which is. I'd be interested in panic logs to sort the issue out, if you could share.

10.10.5 kernel panic too. https://gist.github.com/anonymous/6a76b0793607c890c3ea

You are not vulnerable since you have SMAP!

Re: OS X 10.10.5 kernel local privilege escalation

#95
post #52

Earlier quoted context omitted.

Interesting. I am on 10.10.4 myself, and that's the OS I tested it on. tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. the KASLR leak part is not 100% reliable, unlike the actual code execution which is. I'd be interested in panic logs to sort the issue out, if you could share.

Here's mine: https://gist.github.com/dad0731fc0373a9db858

You are not vulnerable since you have SMAP!

Re: OS X 10.10.5 kernel local privilege escalation

#96

Earlier quoted context omitted.

Are you talking about his comment about -no_shared_cr3, which causes a noticable performance degradation, and how he will be releasing a kext soon - neither of which is mentioned in the github readme, but buried in HN comments? A small portion of users might be considered vigilant, but they're not psychic. The largest target for local privesc are the people who get hit by different kinds of malware, usually as a payl…

I'm counting on the press and community to distribute the information about the no_shared_cr3 workaround and any kext that comes out, just as Apple's fix is most effective when everyone's being told they should be sure it gets applied. There are people in this thread more secure today than they were yesterday, and they owe it to this "irresponsible disclosure." Do they have less of a right to security than the "uneli…

As a bare minimum Apple needs a few hours to analyze the bug, and if the fix is straightforward and doesn't cause any regressions the QA process can begin. Getting the it out to the general public in less than a week is extremely unlikely, and that's provided that they deem it critical enough for an emergency patch (my guess is no). Otherwise we're going to be vulnerable until 10.10.6 and security update 2015-007.

Malware already preys on those least capable of defending themselves, so an unsigned 3rd party kext or a performance degrading boot option does nothing to protect them. We have no indication that this was being exploited by anyone else, if they were that would be newsworthy in itself.

I like your idea of releasing an unofficial patch instead of exploit code though. I still think that you should follow the established responsible disclosure process, but it would at least show some interest in helping users. Oh, and don't be a dick and release it on a Saturday afternoon.

Re: OS X 10.10.5 kernel local privilege escalation

#97
post #75

So we currently have 2 local privilege escalation exploits [1] available for Mac OSX. Apple appears to be in no rush to fix the first one, I wouldn't bet my money on this vulnerability getting a fix any time soon, either ... [1] http://bit.ly/1MrsdID

One of the vulns in this exploit is fixed, rendering the exploit "useless" in 10.11. But start the mac hate train regardless - if facts don't count :)

Why the massive downvotes when contributing to the issue he raises?

> Apple appears to be in no rush to fix the first one, I wouldn't bet my money on this vulnerability getting a fix any time soon, either ...

As it was clearly stated, there is a fix. Whether or not they'll release a 10.10 patch remains to be shown, and "no rush" is speculation.

I'll never understand the HN crowd, but I guess providing additional information to clear up a false statement, while correcting OPs assumptions is against the rules.

Re: OS X 10.10.5 kernel local privilege escalation

#98

Earlier quoted context omitted.

Are you talking about his comment about -no_shared_cr3, which causes a noticable performance degradation, and how he will be releasing a kext soon - neither of which is mentioned in the github readme, but buried in HN comments? A small portion of users might be considered vigilant, but they're not psychic. The largest target for local privesc are the people who get hit by different kinds of malware, usually as a payl…

I'm counting on the press and community to distribute the information about the no_shared_cr3 workaround and any kext that comes out, just as Apple's fix is most effective when everyone's being told they should be sure it gets applied. There are people in this thread more secure today than they were yesterday, and they owe it to this "irresponsible disclosure." Do they have less of a right to security than the "uneli…

This argument is a general argument for is irresponsible disclosure of 0-days.

You don't need omnicience to determine whether the downsides outweigh the potential benefits to a tiny number of jumpy elite who would have to be constantly following and applying patches.

Notably those patches couldn't be applied blindly - so all of those 'elite' in parallel would have to fully understand the exploit and patches lest these become just another attack vector.

There is clearly no justification for this. This isn't just irresponsible. It's a straight up attack on users.

Re: OS X 10.10.5 kernel local privilege escalation

#99

Earlier quoted context omitted.

Malware comes precompiled and ready to run, it doesn't depend on you having a compiler installed.

True that! I'm looking at you, homebrew ..

Not sure why you're looking at Homebrew.

If you're feeling jumpy about binary packages, just set `HOMEBREW_BUILD_FROM_SOURCE="1"` in your shell profile.

Nobody's forcing binaries onto you.

Re: OS X 10.10.5 kernel local privilege escalation

#100

$ git clone https://github.com/kpwn/tpwn.git Cloning into 'tpwn'... remote: Counting objects: 16, done. remote: Compressing objects: 100% (11/11), done. remote: Total 16 (delta 3), reused 16 (delta 3), pack-reused 0 Unpacking objects: 100% (16/16), done. Checking connectivity... done. $ cd tpwn $ make gcc *.m -o tpwn -framework IOKit -framework Foundation -m32 -Wl,-pagezero_size,0 -O3 strip tpwn $ ./tpwn leaked kaslr…

[deleted]
Post reply on HN