Kernel Exploitation Part Five
This post is the five part of my notes from the lecture about kernel exploitation of pwn.college[0]. Read the previous post first:
- Here about the first part.
- Here about the second part.
- Here about the third part.
- Here about the fourth part.
In the last post we did leaned about the kernels’ effort to switch from one ring down to another one and when it becomes necessary. Today we see how the user space relates to the kernel space.
Kernel-Userspace Relationship
Like any other program on your computer does the Kernel have its own address space (dahhh). The different is that the address in memory at a higher address. This is the opposite to User space address.
An artifact of this can be seen when we access the memory map (/proc/self/maps) of a user space program. With the map table exist the vsyscall entry.
However, it is an out-dated function that existed for optimization reasons. The lecturer does not explain this in detail. But it is worth a small side step[1].
Back in the days some syscalls where executed excessively to get quite little information from the kernel. gettimeofday is a good example for it. At some point this became too much overhead that the kernel developers decided to map it into the user space instead. Doing this mapping had some performance advantages. Yet, it introduces many other limitation and issues. In short it is outdated by today’s standard.
The interesting bit is the following: It still exists because application often rely on that fact. In the latest Debian release this was changed and might cause applications to break: They’re still assuming that these four mapped syscalls exists there. However, this was done for some security reasons and make a lot of sense.
Back to the kernel space: The Kernel page access from user space via syscalls do not change the virtual address mapping! That’s probably the reason, why the kernel address are high up in addressing to allow consisted access to the given application. Moreover, it makes sense considering that there is, I think only a single virtual address for the kernel where everything of the kernel resides in.
so far,
akendo
[0] https://pwn.college/modules/kernel
[1] https://stackoverflow.com/questions/19938324/what-are-vdso-and-vsyscall