Found another one of my old exploits. This one a Windows kernel exploit from 2006. :)

This also happens to be one of the exploits I demonstrated (but did not release) at BlackHat and DefCon in 2007, in our Kernel Wars talk. It was actually still unpatched when demonstrating it at BlackHat Europe, even though Microsoft had known about it (but did not think it was exploitable) since 2004. More information about that, and a couple of screenshots, can be found at kernelwars.blogspot.com.

In the demonstration I combined it with an exploit for another 0day we had in Office XP / Microsoft Word, to show the real impact of a privilege escalation exploit such as this one. Nowadays, kernel exploits are probably the most convenient way to break out of browser sandboxes such as the one used in Google Chrome, and of course to enable execution of unsigned code in iOS-based devices such as the iPhone and the iPad. Another nice thing about kernel vulnerabilities is that there are usually far fewer exploit mitigation mechanisms in the kernel than in userspace. ;)

gdixpl.c:

Looking through some old disks now, and found a couple of exploits I coded back in 2004. Good old times. :)

The first one is an exploit for a double free() in CVS <= 1.11.16. It is heavily documented, since I used it as one of the examples in a 6-day course in exploit development and reverse engineering I taught back then. Even though the current malloc() implementations have much more integrity checks now than they did back then, I think the detailed analysis of the exploitation method in the exploit comments can be quite useful to read and understand for people learning exploit development now. There's often a bit too much trial & error involved when novices (and even some experienced exploit developers) code exploits, doing a detailed analysis and understanding every aspect of the vulnerability and the subsystems involved (in this case dlmalloc) is the best approach for making the exploit as reliable as possible. The other one is a format string vulnerability in Courier IMAP <= 3.0.3. This one required DEBUG_LOGIN to be set though, so wasn't that useful in the real world. Since I've always avoided making "target based" exploits with hardcoded addresses and offsets, if not absolutely necessary, the Courier IMAP exploit automatically determines whether the target is Linux or FreeBSD, the offset to the buffer on the stack, the address of the buffer (by first determining the offset to the stack base, with a known address back then when there was no ASLR), and the offset to the saved return address in auth_debug():s stack frame. The shellcode is customized to do a dup2(1, 2) before executing a shell, since fd 1 pointed to the socket descriptor and fd 2 was used for logging errors. Wouldn't want to have the stderr of the shell redirected to a server log. ;) cvs-argx.c:

imap-authdebug.pl: