Local privilege escalation by invalidating the PTR_VALIDATE/ptr_validate/PTR_INRANGE check

[itewqq]

The PTR_INRANGE compared the input address within the range (current_process->image.entry, 0x8000000000000000)

#define PTR_INRANGE(PTR) \
	((uintptr_t)(PTR) > this_core->current_process->image.entry && ((uintptr_t)(PTR) < 0x8000000000000000))

However, it could be bypassed using this:

toaruos/kernel/misc/elf64.c

Line 353 in a54a0cb

this_core->current_process->image.entry = header.e_entry;

which will set the image.entry to whatever we set in a static-linked binary, for example 0x0.

Basically, we can exec a static binary with header.e_entry setting to address lower than the kernel base 0x100000 and use TOARU_SYS_FUNC_MMAP in sys_sysfunc to map the whole kernel image into the user space. Then we just patch the sys_setuid's check and spawn another process to get root shell.

Here is a proof-of-concept that I used in hxp ctf 2024.

[klange]

Glossing over the obvious error of using user-controlled data in a 'security' check, this check doesn't even make sense in the normal case - surely an entirely normal binary could have an entry point that is after some address that would be passed to a system call?

Since Misaka no longer extends the low kernel address space (and doesn't map anything from the kernel low in the aarch64 port), possibly a more sensible check is if the address is after the end of the low kernel mapping - or maybe I should get off my butt and get around to moving the x86-64 kernel to a higher-half mapping...