Last month, while working on the RASMANS "registry corruption" bug with HD, I noticed something odd. The way the bug works is that every time you call the function, the current registry key is deleted and a new one is created with your custom information. You control what is put into the registry key, and the value can be unlimited. The actual deletion and creation is done with windows api calls, and the RPC function is just a remote interface to the modification of those specific keys. Seems pretty safe. The only problem is that the API to modify a registry key has a little problem. If the key is over a certain size, a stack based buffer overflow occurs and you're in trouble. The exploit works by just calling once to set the key to a huge value, then calling the function again to have our huge value deleted, thus triggering the overflow.
The overwrite occured inside the reg function, but nothing in ADVAPI was changed. So the problem was either ADVAPI or some argument to it... I forgot about this for awhile due to a flood.
Well, it's MS Tuesday again, and what do I see? MS06-036. A quick bindiff, and 15 seconds looking at the changed function, and I knew immediately what the vulnerability was. Registry registry registry.
I'll leave it as an exercise to the reader to find what other remotely accessible services let you write an arbitrary value to a registry key with RegSetValueExW.
The bug exists in the improper use of the Registry functions. (Alex Sotirov clued me in to this.) Apparently, they take a buffer size in TCHARs rather than in chars (or bytes), and many functions that call them incorrectly assume the size is in bytes. So you can probably still find vulnerable functions, but the only way to fix it is to find every function that has incorrectly given the buffer size and fix it manually. This is no easy task in the least. My apologies to MS and to the rest of you for the misinformation ;)
Still, it's certainly worth the time to hunt down all remotely accessable functions that allow you to set registry keys to find this problem. Thanks Alex!