Re: Backport of the integer overflow in the brk system call

[Isaac To <kkto@csis.hku.hk>]

>>>>> "Jonathan" == Jonathan Dowland <jmtd@bylands.dur.ac.uk> writes:

    Jonathan> On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler
    Jonathan> wrote:
    >> Afaik: 2.4.23 contains literally 100s of changes, one of these was a
    >> small change to do_brk(), which looked like a normal non-critical
    >> bugfix to everybody involved. Some time later Debian was hacked and
    >> backtracing how the intruder got superuser privileges revealed that
    >> that the do_brk() without the "small change" was guilty, it had been
    >> no simple bug but a local privilege escalation issue.

    Jonathan> My understanding is that the do_brk vulnerability allowed
    Jonathan> access to kernel address space. It seems a lot of work is
    Jonathan> needed to move from that freedoom to spawning a root
    Jonathan> shell. I'd be interested in seeing a worked example.

Actually I'm staring at the code for hours without much success about how to
write anything in the kernel.  It does not literally allow access to the
kernel address space: if it does so, all you need to do is to traverse the
kernel data structures to find where is the task_struct for the process
itself and change the EUID to 0 in order to get root.  What the bug gives is
a memory region that extends through the kernel memory.  The process cannot
access that region: it is protected, and you can read it only in kernel
mode.  You cannot try to pass that as an address buffer to a system call
either: system calls check whether address is past the end of process
address space.  So the program must somehow trick the kernel into accessing
the region by itself, and since the kernel believes the correctness of the
region it will not do any further checking.  The only way that readily comes
to mind is to let the program core dump: the kernel will most likely happily
read all the kernel memory and save it into the core file.  But it is still
rather far from changing anything in the kernel memory.  Andreas is
definitely right that the hole doesn't look like that it is that dangerous.

Regards,
Isaac.