- Joined
- Jan 22, 2014
- Messages
- 245
- Trophies
- 0
- Age
- 26
- Location
- Japan
- Website
- 173210.github.io
- XP
- 683
- Country
Hello, I found something. I just found something and it may not be useful. Anyway, I'll post this because I don't know SVC handler well and have no idea where the function is. If you know how to find the actual code of SVC, please tell me. I'm a noob for 3DS.
3DS System Flaws - 3dbrew
http://www.3dbrew.org/wiki/3DS_System_Flaws
Usually 3dbrew writers don't provide actual unknown vulnerabilities, so I'm still wondering the following description is correct.
So, I wrote this simple PoC by modifying an example included in ctrulib.
svcCreateThread actually returned 0 and the created thread didn't seem to work. So, my experiment is successful, probably.
Anyway, notice the following things.
KTR 9.2: Confirmed it accepts a negative value.
CTR 9.9: Confirmed it has the vulnerable code at 0xfff079b4.
CTR 4.5: Confirmed it has the vulnerable code at 0xfff07b2c.
Update on 3dbrew.org
So I carried out another experiment. It crashed when it took -4 as processorid on n3ds. So it may write the data in the same place as it does when it took 4 as processorid. It's still not clear whether it's exploitable or not.
I may have to develop ARM11 debugger...
3DS System Flaws - 3dbrew
http://www.3dbrew.org/wiki/3DS_System_Flaws
Usually 3dbrew writers don't provide actual unknown vulnerabilities, so I'm still wondering the following description is correct.
Yellows8 doesn't mention about the possibility of the case that s32_processorid is negative. It can result in kernel memory corruption, and eventually kernel code execution.Yellows8 said:The svcCreateThread changes with 10.0.0-Xdefinitely did fix a security issue.
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <10.0.0-X. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:
- Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
- New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
- Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
- New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).
So, I wrote this simple PoC by modifying an example included in ctrulib.
Code:
diff --git a/examples/threads/event/source/main.c b/examples/threads/event/source/main.c
index 1fcec86..dbe1d9e 100644
--- a/examples/threads/event/source/main.c
+++ b/examples/threads/event/source/main.c
@@ -36,7 +36,7 @@ int main(int argc, char** argv) {
svcCreateEvent(&threadRequest,0);
u32 *threadStack = memalign(32, STACKSIZE);
- Result ret = svcCreateThread(&threadHandle, threadMain, 0, &threadStack[STACKSIZE/4], 0x3f, 0);
+ Result ret = svcCreateThread(&threadHandle, threadMain, 0, &threadStack[STACKSIZE/4], 0x3f, -2147483647);
printf("thread create returned %x\n", ret);
Anyway, notice the following things.
- It has so many limitations and is not so easy to exploit.
- It's just an ARM11 kernel vulnerability, not ARM9.
KTR 9.2: Confirmed it accepts a negative value.
CTR 9.9: Confirmed it has the vulnerable code at 0xfff079b4.
CTR 4.5: Confirmed it has the vulnerable code at 0xfff07b2c.
Update on 3dbrew.org
According to 3dbrew.org, s32_processorid should be larger than -4, which is the code-reversed value of the number of n3ds core.The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).
So I carried out another experiment. It crashed when it took -4 as processorid on n3ds. So it may write the data in the same place as it does when it took 4 as processorid. It's still not clear whether it's exploitable or not.
I may have to develop ARM11 debugger...
Last edited by 173210,
, Reason: Add "Update on 3dbrew.org"