Phrack 58 appeared in late December and has been my reading project for the past fortnight. Two articles in particular deserve writeup.
Heap exploitation, formalised
The first article is on heap-based buffer overflows. Stack overflows have been well-understood for years; heap overflows have been more sporadic, with each specific exploitation tied to specifics of the heap implementation.
This article systematises the technique. The core insight: the heap allocator's metadata — the linked-list pointers that connect free blocks — is itself in the heap, alongside the application's data. A buffer overflow that overwrites the metadata of an adjacent block can corrupt the allocator's state. When the corrupted free block is later freed (by free() or in unlink() macro operations), the corrupted pointers are written through, producing an arbitrary write primitive.
The technique is general across glibc-based Linux systems. Once you have the write primitive, the same techniques as for format-string bugs apply — overwrite the GOT, overwrite a function pointer, redirect control flow.
The defensive implications are significant. Many daemons have buffer overflows on heap-allocated buffers; until now those bugs were treated as harder to exploit than stack overflows. The new technique closes much of the gap. Heap overflows are now exploitable with similar reliability to stack overflows.
This is going to produce, over the next year, a wave of advisories that re-examine bugs previously categorised as denial-of-service-only and find them to be code-execution issues.
Advanced kernel rootkit techniques
The second article extends the kernel rootkit work from Phrack 55. The new techniques:
Hooking via VFS instead of syscall table. Earlier rootkits hooked the syscall table — getdents, kill, read. Modern Linux kernels detect syscall-table modifications more readily; the next-generation rootkits hook at the VFS layer, intercepting filesystem operations at the level above syscalls. The techniques are stealthier and harder to detect.
Hiding modules from lsmod. A rootkit module that, once loaded, removes itself from the kernel's loaded-module list. The module continues to run; tools that report loaded modules cannot find it.
Direct manipulation of running processes. Modifying a process's task_struct directly, hiding it from process listings without going through the syscall layer. The process continues to schedule and run; standard tools cannot see it.
The escalating sophistication is the trend. Each generation of rootkit defeats the detection methods of the previous generation. The defensive answer continues to be off-host inspection — booting from clean media, comparing the live system against a known-good baseline. There is no on-host detection that survives.
What this changes for defenders
Heap overflows deserve the same urgency as stack overflows. Operators should not assume that a "denial of service" advisory is harmless. Many of these will turn out to be code-execution issues as the techniques mature.
Off-host integrity checking is now structurally necessary. Any defensive posture that depends on the host being able to detect its own compromise is failing. The Lion rootkit and the techniques in this Phrack article both rely on the same insight: an attacker with kernel access can hide arbitrarily well from on-host inspection.
The arms race is faster than the defensive deployment. Each new technique reaches operational deployment within months. The defensive techniques (file-integrity monitoring from clean media, kernel-module verification, hardware-based attestation) take years to deploy at scale.
What I am doing
I have updated my own monitoring to do file-integrity checks from a separate machine that boots from a CD-ROM and mounts the suspected disk read-only. The discipline is awkward but is, on the available evidence, the only reliable approach.
For my honeypot, the new techniques are exactly what I want to capture. The Sebek module provides off-host visibility into syscall-level activity even when on-host tools are compromised. I am deploying it next week.
More in the coming weeks.