Written by akendo on 
3 minutes reading posted in Security
with tags: kernel 100daystooffload

Kernel Exploitation Part Six

This post is the sixth and last part of my notes from the lecture about kernel exploitation of pwn.college[0]. This also concludes the first lecture. Read the previous post first:

In the last post we did leaned about the kernel relationship to the user space. Today we see how the attack are happening in the kernel.

Before we’re going to get into the attack itself, it is worth to mention that kernel code is just code. Hence, all types of vulnerabilities affecting the code base too. I’m aware of the fact, that the kernel has some mitigation strategy to prevent format string vulnerabilities.

A good example for an exploit was the ping of death. It included several useful aspects. Remotely and was often rather simpler to exploit. However, it was more common back in the 90s.

More modern exploit User space like syscall handles or interfaces of the kernel. This is mostly used to exploit sandboxes.

Here some note: That’s one problem that docker has. It isolates process from within the kernel by using namespaces. However, unlike a VM all these names spaces share the same kernel. Leading to the underlying problem that an attacker can exploit syscalls (I think there are around 200 of them). That’s why you should and isolation layer in between. In modern clouds environments we often see that various clients will have all their container within a VM of it its own. But also there are some nice abstraction to have more isolation on the syscall level. gvisor[1] it is called.

Their exploit accesses due resources that is provided due to performance reasons.

Remember in the previous post about the vsyscall mapping? Here is the thing why it was replaced. For once, it had only a limitation of four syscalls, BUT it was a kernel function that was read only where an attack could use some ROP to change the invoking parameters[2]. That’s not a desirable outcome, isn’t it?

What we see is the difficulties of overlapping between kernel and user space boundaries. How hard it is to get it right and make sure that things are not going south. I think the vsyscall is a perfect example. None of the developers did think that it could be exploited that way.

I think that’s why he’s mention this feature, it’s a low-hanging fruit that can be found by some simple googling around.

Besides of this hidden example, an exploit can be executed by a device driver. There are even specified devices that can exploit it. teensy for instance.

There is a battery of broken hardware driver within the kernel bug tracker. Many found by fuzzers like Skycaller. The main problem here is that most maintainer are not reachable anymore or some other problem to get them to fix it. Hence, it is a good attack vector for exploitation.

Once you have established the necessary access level you want to pursue different goals:

One hit I like to add is to own/pwn the machine, Apple iPhones for instance do not grant root privileges to you. Hence, running an exploit is the act of taking control and ownership.

This concludes the first lecture. I felt like that the last slides provided too much value information, at least for me. Next is to setup the testing environment.

so far,
akendo

[1] https://gvisor.dev/
[2] https://lwn.net/Articles/446528/