At work today, I had a security hole to investigate. Say what you like about Microsoft, but you have to admit that in recent years they have really turned things around on the front of taking security seriously. It was interesting to get to experience this from the inside today.
As it turned out, all the Microsoft Security Response Center wanted to know was if this bug (which is known to affect certain no-longer-supported parts of Visual Studio 6) also affected the later versions (Visual Studio .NET, Visual Studio .NET 2003 and Visual Studio 2005). Rather than just testing the exploit against these later versions, I insisted on debugging through the VS6 code to find the faulty code and then making sure that this code was fixed in the later versions.
It's quite a strange experience to be debugging through such old code (some of it at least a decade old) especially when I work every day on the code that is descended from it. It's kind of like going back in time and meeting your ancestors. There are some strangely familiar things there but it is very much code from another time. It's also much simpler with 10 years fewer layers of features and added special cases. I was surprised at how easy the bug was to track down.
It was also a relief that, when I found the right place, the bug was completely obvious to any (modern day) programmer looking at the routine in question. Rather than being some subtle and hard-to-spot side-effect of a rare interaction between unrelated parts, the faulty code was doing all the things you're not supposed to do, like allocating a fixed-length buffer on the stack and concatenating C-style strings without any size checks. Such code could never get into the product with the processes we have in place now.
Amazingly, the function with the fault still exists in the codebase today, though the buffer overrun was fixed a long time ago (sometime before November 2000, when the code was moved to the version control system we currently use). It's good to know that when issues like this come up we can track them down quickly even in ancient code, and that our processes work.