Homebrew [Need Implementation] 3DS ARM11 Kernel Exploit by TuxSH

[NexoCube]

Hello, 2 days ago, @TuxSH revealed (on 3dbrew) a bug he found in ARM11 Kernel.

Summary : svcGetThreadList (svc 0x66) process reference leak

Description given : When given a valid process handle (including 0xFFFF8001), svcGetThreadList forgets to decrement the reference count of the underlying KProcess instance, after having finished using it.

What could happen if we exploit this bug : Before 11.2: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable

Note (by me, lol) :

- 0xFFFF8001 = Current KProcess Handle
- Kernel Objects are C++ Virtual Classes : So, it means vtable (so, if you find a UAF bug in KObject management, it is "probably" exploitable)

From what i understood ; if that UAF were exploitable, it would lead to K11 Code Execution, because it means vtable call (from a forged vtable)

and pssstt... kernel exploit doesn't always mean code execution

 

[Arck]

just check how the fasthax "System Flaws" work on 3dbrew and check his repo so you can easily compare.

 

[GhostLatte]

TheKingy34 already implemented it.

 

[Arck]

TheKingy34 already implemented it.

wow so funny

 

[NexoCube]

just check how the fasthax "System Flaws" work on 3dbrew and check his repo so you can easily compare.

ehe, i watched 33c3 and read the desc

 

[Giodude]

Interesting, more or less interested in the idea of arm11loaderhax coldbooting a custom OS vs installing an entire new one.

 

[NexoCube]

Interesting, more or less interested in the idea of arm11loaderhax coldbooting a custom OS vs installing an entire new one.

I heard each CPU have his bootrom, so, maybe someone can find a bug in the ARM11 BootROM

 

[rotomington]

I heard each CPU have his bootrom, so, maybe someone can find a bug in the ARM11 BootROM

According to derrek, there really isn't anything interesting in prot_boot11.bin or unprot_boot11.bin. All the fun stuff's in prot_boot9.bin.

Although, if there are any bugs in the arm11 bootrom, they wouldn't be of much use since we'd need to reboot and have code execution just after boot (Which if you have, you might as well exploit the arm9 like in A9LH)

 

[NexoCube]

According to derrek, there really isn't anything interesting in prot_boot11.bin or unprot_boot11.bin. All the fun stuff's in prot_boot9.bin.

Although, if there are any bugs in the arm11 bootrom, they wouldn't be of much use since we'd need to reboot and have code execution just after boot (Which if you have, you might as well exploit the arm9 like in A9LH)

ARM9 boot time exploi is much more needed because it means we have have full control over the 3DS a few milliseconds after boot

 

[adrifcastr]

wow, nobody seems to care that an implementation of this could actually lead to kernel11 code execution.
If I was any good in C/C++
I would go and try, but I'm not good at all.

 

[metroid maniac]

Not that I want to hijack this thread, but I'm curious about something.
How exactly can a use-after-free bug lead to an arbitrary code execution exploit in an NX environment?
I assume the first step once you have a user-after-free bug would be to make a phony vtable with function pointers to useful gadgets, and then corrupt the free'd object so its vptr points to your vtable.
But then, how can you execute multiple gadgets in a row? Once your gadget executes, won't you just return to the regular program flow?

 

[TuxSH]

The bug I mentioned isn't usable, and very likely not exploitable (and not exploitable at all since 11.3).

tl;dr nothing to see here

 

[NexoCube]

The bug I mentioned isn't usable, and very likely not exploitable (and not exploitable at all since 11.3).

tl;dr nothing to see here

Oh okay