No subject

    ...It is really a matter of (1) moving the program origin
    up into the highest part of virtual memory, where the
    stack usually lives, and (2) shorting out the C library's
    startup code which sets up the address space in the first
    part. Once you do that, an unpatched system will happily
    expand your heap area into kernel space.

    So, as the Debian Project learned at great cost, this little
    omission in the implementation of the brk() system call is
    fully usable for a complete local root exploit.

    There have been a lot of questions about how such a
    vulnerability could remain unfixed for so long. In fact,
    it was patched in the 2.6.0-test series almost as soon
    as it was found. The fix also went to Marcelo Tosatti,
    the 2.4 maintainer, but it was too late for the 2.4.22
    release, which happened on August 25. So the fix was
    merged into 2.4.23-pre7, which came out on October 9.
    The current 2.4.23 kernel is not vulnerable - but that
    was too late to help Debian.

    The real problem, of course, is that nobody realized the
    severity of this bug. Had the kernel developers understood
    that current kernels were vulnerable to this sort of attack,
    the alert would have gone out and the various distributors
    would have sent out the usual set of updates. But this patch
    was just one of over 2000 patches merged by Linus in September.
    It would seem that it simply became part of the stream of
    fixes, and nobody looked at it particularly closely.

It's a really hairy story, therefore. It makes me proud of Linux
so see how the community has handled it.

-Bill