Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X 10.10.5 kernel local privilege escalation

github.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#61

Post by amluto »

clebio wrote: post #39
qwertyoruiop wrote: post #34

Earlier quoted context omitted.

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.

Could you provide some context for that? What does that flag do? How do you even set boot args for OSX? I have little context to OSX boot process, and would like to understand this better.

CR3 is the x86 register that points to the root page table. When an OS switches between processes, it generally changes CR3. On the other hand, when an OS switches from user mode to kernel mode, it usually leaves CR3 alone.

I know essentially nothing about Darwin, but "no shared CR3" presumably means that the kernel will switch CR3 to make user memory inaccessible when running in kernel mode. This is approximately what grsecurity's UDEREF feature does.

On Linux, on Broadwell or newer, there's a similar HW mitigation called SMAP. Darwin might use it, too.

Linux also doesn't allow unprivileged programs to map very low addresses, making NULL pointer dereferences much harder to exploit.

Re: OS X 10.10.5 kernel local privilege escalation

#62

Post by devy »

qwertyoruiop wrote: post #13
readme wrote: post #11

Earlier quoted context omitted.

Yep, same result here on 10.10.4 heh.

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

Re: OS X 10.10.5 kernel local privilege escalation

#63

Post by glitch »

clebio wrote: post #53
qwertyoruiop wrote: post #44

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…

Well, I was more looking for an explanation of what "no shared CR3" means. What is CR3, how do I know to go to that option as a way to disable this exploit. And, coming from a Grub/ubuntu perspective, when you say "boot args", I think of the boot loader, which for Grub is configured with config files (text files) or else at boot-time, via the Grub menu. I know OSX has a single-user mode, but don't know of a way to ed…

CR3: https://en.wikipedia.org/wiki/Control_register#CR3

Some relevant excerpts from Mac OS X and iOS Internals: To the Apple's Core by Jonathan Levi:

From page 133: In 64-bit mode, there is such a huge amount of memory available anyway that it makes sense to follow the model used in other operating systems, namely to map the kernel’s address space into each and every process. This is a departure from the traditional OS X model, which had the kernel in its own address space, but it makes for much faster user/kernel transition (by sharing CR3, the control register containing the page tables).

From page 266: Still, unlike Windows or Linux, OS X applications in 32-bit (Intel) used to enjoy a largely unfettered address space with virtually no kernel reservation — that is, the kernel had its own address space. Apple has conformed, however, and in 64-bit mode OS X behaves more like its monolithic peers: the kernel/user address spaces are shared, unless otherwise stated (by setting the -no-shared-cr3 boot argument on Intel architectures). The same holds true in iOS, wherein XNU currently reserves the top 2 GB of the 4 GB address space (prior to iOS version 4 the separation was 3 GB user/1 GB kernel).

Re: OS X 10.10.5 kernel local privilege escalation

#64

Post by akerl_ »

devy wrote: post #60
benwilber0 wrote: post #6

$ 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…

I did the same, didn't get the root shell but instead got a standard OS X kernel panic screen and system reboot twice before it came back to life. And wtf @qwertyoruiop this is how you "responsibly" release zero day?! I just upgraded to 10.10.5 yesterday!

You have quotes around "responsibly", is that a quote from somewhere in this disclosure?

You're welcome to point out that you prefer that vulns be disclosed to vendors before public release, but to chastise someone for not subscribing to your preferred methodology seems a bit off base

Re: OS X 10.10.5 kernel local privilege escalation

#65

Post by scintill76 »

Jerry2 wrote: post #55
koenigdavidmj wrote: post #43

Earlier quoted context omitted.

Apple traditionally has a poor record of responding to delayed disclosures. They burned that bridge a long time ago.

No they did not. Provide some evidence please. They've responded to hundreds of security issues and have credited people in security updates. About the only incident that I can recall is the Google one when Google automatically disclosed vuln's after Apple asked them for more time since it affected a very deep kernel issue.

My vague recollections of past vulns (and admitted dislike for Apple) leads me to believe the parent comment, so I did some Googling. "A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw."[1] But hey, they did credit him in the release notes!

Granted, it's been several years now, but the parent did say "has a poor record", and a 3 year patch delay fits that description.

More recently, there was the 4-day gap[2] between patching "goto fail" on iOS vs. OS X. While not really the same point as the parent comment, it reflects poorly on their commitment to rapidly fixing things.

[1] http://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix... [2] http://www.cnet.com/news/apple-finally-fixes-gotofail-os-x-s...

Re: OS X 10.10.5 kernel local privilege escalation

#66

Post by 0x0539 »

nnx wrote: post #54
qwertyoruiop wrote: post #44

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?

OSX should be doing the context switch also.

The added penalty is a switch to usermode to read userland data, then a switch back to kernel to continue on...its just additional context switches for reading userland memory

Re: OS X 10.10.5 kernel local privilege escalation

#67

Post by MagerValp »

scintill76 wrote: post #65
Jerry2 wrote: post #55

Earlier quoted context omitted.

No they did not. Provide some evidence please. They've responded to hundreds of security issues and have credited people in security updates. About the only incident that I can recall is the Google one when Google automatically disclosed vuln's after Apple asked them for more time since it affected a very deep kernel issue.

My vague recollections of past vulns (and admitted dislike for Apple) leads me to believe the parent comment, so I did some Googling. "A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw ."[1] But hey, they did credit him in the release notes! Granted, it's been several years now, but the parent did say "has a poor re…

Apple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after.

I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even trying is just irresponsible. There's a lot of room for improvement in Apple's handling of vulnerabilities, especially with regards to response time and proactive work, but I don't see how deliberately waiting until 10.10.5 and then releasing a 0-day is helping anyone.

Re: OS X 10.10.5 kernel local privilege escalation

#69

Post by scintill76 »

MagerValp wrote: post #67
scintill76 wrote: post #65

Earlier quoted context omitted.

My vague recollections of past vulns (and admitted dislike for Apple) leads me to believe the parent comment, so I did some Googling. "A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw ."[1] But hey, they did credit him in the release notes! Granted, it's been several years now, but the parent did say "has a poor re…

Apple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after. I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even…

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.

Re: OS X 10.10.5 kernel local privilege escalation

#70

Post by MagerValp »

scintill76 wrote: post #69
MagerValp wrote: post #67

Earlier quoted context omitted.

Apple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after. I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even…

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 payload in sleazy spyware installers. The malware authors now have a few profitable weeks before Apple patches it (here's hoping they're quick!) and only the elite few who know how to deploy an unsigned kext (that still isn't available) will be able to protect themselves.

Still not seeing the upside to this.

Post reply on HN