I have asked on Twitter if anyone could sign it for me. For some reason neither of the two people who tried to do so were able to sign it. No idea why. kexts were signed but they kept getting rejected for some reason.
iOS is vulnerable too as far as the vulnerability is concerned. It is not directly exploitable on iOS, however having a NULL task_t still does give you some abilities, even if not (directly?) SVC code exec.
while I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory…
well, this bug is a null pointer deference. smap is like -no_shared_cr3, but without the performance loss.
Then you should not install them on a machine with confidential data at all, source or binary. It's that simple!
for the record: "At 0x20 I place a POP RAX;RET gadget" should be "At 0x18 I place a POP RAX;RET gadget".
for the record: i had no idea yesterday was saturday at the time I dropped the code.
I did not have the patch ready when the exploit was published, that's the only reason why. I had my reasons to publish the exploit in public yesterday, but all I can say is "no comment". Just for the record: I did…
> and the author made no effort at all to reduce the impact http://github.com/kpwn/NULLGuard
You are not vulnerable since you have SMAP!
If the heap info leak fails, I bail out cleanly. If the kASLR leak fails, it is usually because instead of hitting a vm_map_copy (the intended structure I need to corrupt), something completely unrelated is hit instead.…
1) I cannot really discuss specifics, but this particular bug would have been hard to find via a traditional IOKit fuzz, since it requires an invalid 'task' port passed over to IOServiceOpen. Most fuzzers use…
'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…
Yes, it is.
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.
> tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. 10.10.3 was actually the first version it was tested on.
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…
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…
> A TB of traffic will cost at least around €2-3 from most european (and other) ISPs with VPS The average bandwidth price I got from all the ISPs I used in the past was ~1 dollar/megabit. The ISPs I used for my Tor…
I'm a 15 year old 'kid` that has been pushing 30TB/day traffic thru a few Tor exits for months just fine, because I truly believe in freedom of speech. You know, money isn't that hard to get. For me, a few weeks of…
I have asked on Twitter if anyone could sign it for me. For some reason neither of the two people who tried to do so were able to sign it. No idea why. kexts were signed but they kept getting rejected for some reason.
iOS is vulnerable too as far as the vulnerability is concerned. It is not directly exploitable on iOS, however having a NULL task_t still does give you some abilities, even if not (directly?) SVC code exec.
while I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory…
well, this bug is a null pointer deference. smap is like -no_shared_cr3, but without the performance loss.
Then you should not install them on a machine with confidential data at all, source or binary. It's that simple!
for the record: "At 0x20 I place a POP RAX;RET gadget" should be "At 0x18 I place a POP RAX;RET gadget".
for the record: i had no idea yesterday was saturday at the time I dropped the code.
I did not have the patch ready when the exploit was published, that's the only reason why. I had my reasons to publish the exploit in public yesterday, but all I can say is "no comment". Just for the record: I did…
> and the author made no effort at all to reduce the impact http://github.com/kpwn/NULLGuard
You are not vulnerable since you have SMAP!
You are not vulnerable since you have SMAP!
If the heap info leak fails, I bail out cleanly. If the kASLR leak fails, it is usually because instead of hitting a vm_map_copy (the intended structure I need to corrupt), something completely unrelated is hit instead.…
1) I cannot really discuss specifics, but this particular bug would have been hard to find via a traditional IOKit fuzz, since it requires an invalid 'task' port passed over to IOServiceOpen. Most fuzzers use…
'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…
Yes, it is.
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.
> tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. 10.10.3 was actually the first version it was tested on.
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…
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…
> A TB of traffic will cost at least around €2-3 from most european (and other) ISPs with VPS The average bandwidth price I got from all the ISPs I used in the past was ~1 dollar/megabit. The ISPs I used for my Tor…
I'm a 15 year old 'kid` that has been pushing 30TB/day traffic thru a few Tor exits for months just fine, because I truly believe in freedom of speech. You know, money isn't that hard to get. For me, a few weeks of…