shraptor <shrap...@bahnhof.se> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
