shraptor <shraptor@???> writes:
> On 2016-01-19 19:07, Rainer Weikusat wrote:
>> In this particular case, an unprivileged local user could gain root
>> access by running a program which does billions of syscalls as fast as
>> it can for ca 30 minutes (according the 'real' article).
>
> I tested the program in the 'real' article but it didn't work?
>
> But I guess you have to adjust addresses of commit_creds and
> prepare_kernel_cred functions for my kernel version?
> The article says they are static and can be determined per Linux
> kernel version.
>
> How to determine those?

You can find them in the System.map file for your kernel, eg,

[rw@doppelsaurus]~#grep prepare_kernel_cred /boot/System.map-4.4.0-net
ffffffff810555f0 T prepare_kernel_cred
ffffffff8179d680 R __ksymtab_prepare_kernel_cred
ffffffff817acd40 r __kstrtab_prepare_kernel_cred

The T entry is the address of the function.

> some kind of stacksmashing?

No. The bug in the kernel function causes a reference to some object to
be leaked, ie, the reference count is incremented but not
decremented. This can be used to increment the count until the value
overflows to 0. The kernel will then free the object but without
invalidating the handle to it on the wrong presumption that since
refcount == 0, no handle exists anymore. These objects are allocated via
kmalloc which is a power-of-two freelist allocator. The implies that
it's possible to get the kernel to reuse the erroneously freed object
for 'something different' of a suitable size and users can copy
arbitrary data into the corresponding buffer. That used to create a
mock 'original object' with a function pointer value in it which points
to an application function accomplishing the privilege escalation. Since
the process still has a valid handle to the freed object, this handle
can be used to invoke a system call working with the user-supplied new
content of the corresponding memory area which then causes the kernel
to call the exploit function.