I'm running 10.10.4, and it just crashed my Mac -- the "A problem has occurred" screen -- followed by a forced restart.
Yep, same result here on 10.10.4 heh.
OS X 10.10.5 kernel local privilege escalation
11–20 of 143 posts
Re: OS X 10.10.5 kernel local privilege escalation
#12$ 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…
Nice to see a 100% working widely exploitable 0day without any caveats that make it not real-world applicable. Local, so you need a non-admin account on the box which is kinda hard.
Re: OS X 10.10.5 kernel local privilege escalation
#13I'm running 10.10.4, and it just crashed my Mac -- the "A problem has occurred" screen -- followed by a forced restart.
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.
Re: OS X 10.10.5 kernel local privilege escalation
#14So for anyone who hasn't tried it but is wondering about it - it works on 10.10.4 and 10.10.5, running the tpwn binary does drop you to a root shell. Looks like a weakness in the address randomization in OS X
I haven't look into this vulnerability, but how could it be a weakness in address randomization? Isn't address randomization supposed to be a mitigation, to make it more difficult to exploit other vulnerabilities.
There is no weakness in address randomization I relied on for exploitation.
It relies on two distinct bugs, an info-leak to obtain a pointer to an allocation in the kalloc.1024 zone and a memory corruption primitive (deriving from a NULL pointer dfr. in IOKit) allowing me to OR 0x10 anywhere in kernel memory.
To break kASLR I corrupt the size of a vm_map_copy struct, which allows me to read the adjacent allocation to the struct, which is a C++ object. First 8 bytes of said C++ object is a pointer to the vtable, which resides in __TEXT of some kernel extension. Since I can calculate the unslid address from userland without any issue, by subtracting what gets leaked with what gets calculated you get to know the kASLR slide.
Just to clarify: The code execution part has 100% reliability rate. The kASLR leaking part does have some chance in it, however empirical evidence indicates that the failure rate is extremely low.
Re: OS X 10.10.5 kernel local privilege escalation
#15$ 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…
Nice to see a 100% working widely exploitable 0day without any caveats that make it not real-world applicable. Local, so you need a non-admin account on the box which is kinda hard.
I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.
Re: OS X 10.10.5 kernel local privilege escalation
#16Earlier quoted context omitted.
Nice to see a 100% working widely exploitable 0day without any caveats that make it not real-world applicable. Local, so you need a non-admin account on the box which is kinda hard.
I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.
You can also use it to build malware that would normally be defeated by an unprivileged account right?
Re: OS X 10.10.5 kernel local privilege escalation
#17Earlier quoted context omitted.
Nice to see a 100% working widely exploitable 0day without any caveats that make it not real-world applicable. Local, so you need a non-admin account on the box which is kinda hard.
I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.
Go ahead and give us an example.
Re: OS X 10.10.5 kernel local privilege escalation
#18Earlier quoted context omitted.
I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.
You can also use it to build malware that would normally be defeated by an unprivileged account right?
A java applet could exploit this. With a little work, a Flash load in Safari (or really any browser) could probably exploit it.
This is a real 0day.
Re: OS X 10.10.5 kernel local privilege escalation
#19Does it work on 10.11 with "rootless" mode disabled?
I just tested on 10.11 with rootless being disabled, and it prints out "not vulnerable".
I assume that if it doesn't work on 10.11, then rootless being enabled or disabled shouldn't make a difference. You still have a root user either way, it's just that if rootless is enabled, then the root user wouldn't be able to modify certain system directories, which could mitigate the consequences of such an attack if it did work.
Re: OS X 10.10.5 kernel local privilege escalation
#20Interesting. This prompted me to look at my Mac and it's running 10.10.3, I never got a prompt to update to 10.10.4 or 10.10.5, but when I open App Store it tells me there's an upgrade to 10.10.5. I guess Apple managed to break the automatic update mechanism in 10.10.3.
I wonder if this is related to the behavior where my iMac wakes up every minute starting every morning at 2AM. This is so obnoxious that I now turn my iMac off at night instead of putting it to sleep.