qwertyoruiop

5 ms·

1.
by qwertyoruiop 11y ago
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.
2.
by qwertyoruiop 11y ago
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.
3.
by qwertyoruiop 11y ago
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 write-what-where, which i
4.
by qwertyoruiop 11y ago
well, this bug is a null pointer deference. smap is like -no_shared_cr3, but without the performance loss.
5.
by qwertyoruiop 11y ago
Then you should not install them on a machine with confidential data at all, source or binary. It's that simple!
6.
by qwertyoruiop 11y ago
for the record: "At 0x20 I place a POP RAX;RET gadget" should be "At 0x18 I place a POP RAX;RET gadget".
7.
by qwertyoruiop 11y ago
for the record: i had no idea yesterday was saturday at the time I dropped the code.
8.
by qwertyoruiop 11y ago
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 inform Appl
9.
by qwertyoruiop 11y ago
> and the author made no effort at all to reduce the impact http://github.com/kpwn/NULLGuard
10.
by qwertyoruiop 11y ago
You are not vulnerable since you have SMAP!
11.
by qwertyoruiop 11y ago
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. If it happens to hit
12.
by qwertyoruiop 11y ago
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 mach_task_self for th
13.
by qwertyoruiop 11y ago
'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 use
14.
by qwertyoruiop 11y ago
Yes, it is.
15.
by qwertyoruiop 11y ago
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.
16.
by qwertyoruiop 11y ago
> 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.
17.
by qwertyoruiop 11y ago
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 po
18.
by qwertyoruiop 11y ago
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
19.
by qwertyoruiop 14y ago
> 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 relays were ISPs I wa
20.
by qwertyoruiop 14y ago
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 coding got me a few thous