The most infamous Microsoft patch of all time, in security circles at least, is MS08-067. As the name suggests, it was the 67th security update that Microsoft released in 2008. Less obviously, it fixed a huge problem in a file called netapi32.dll. Of course, 2008 was a long time ago in computing circles, but not far enough. I still hear stories about production servers that are missing MS08-067.
Last week, Microsoft took a look back at MS08-067, sharing some of its own war stories, including how they uncovered the vulnerability, developed a fix, and deployed it quickly. It’s unclear who besides Microsoft knew about the problem at the time, but one must assume others were aware of it and using it. They certainly were after the fall of 2008.
In 2008 when this patch was released, I was a sysadmin. I’d had my Security+ certification for a little more than three weeks, but at that point in my career, I’d been pushing patches for a living for around five years. I was an Air Force contractor, responsible for pushing patches to a few hundred mission-critical servers that, among other things, tracked flight crews, cargo planes, and tankers. Our contract required 99.999% uptime–knowing where your planes and flight crews are is kind of important–and we blew the doors off that requirement, in spite of a second contractual requirement that stated we would get patches down in a timely fashion, as decided by the government. Government deadlines varied widely, but in the four years total that I did it, only two patches gave me significant trouble. MS08-067 wasn’t one of them.
I was good at my job.
I do remember MS08-067 getting special attention since it was widely exploited early, but I didn’t sweat any of it. I just had to furnish extra proof that we’d gotten the patch down. Most likely I wrote a batch file that ferreted out the knowledge base article and located the time/date stamp on that particular log file, compiled a list, and sent it off to the information assurance analysts. My then-boss hated when I did stuff like that, but it was precisely because I did things in a consistent, automated fashion that MS08-067 was never a problem for us. I’m pretty sure MS08-067 never appeared on his radar at all.
To me it was just another patch, and not worth worrying about. By 2008, if I had any trouble getting a patch down, I had the tools to find and correct it long before the information assurance group would see it, so I didn’t have any problems. A patch was a patch was a patch.
Years later, after I became an information assurance analyst myself, I learned what the big deal about MS08-067 was. It allowed unauthenticated remote code execution, and it worked about 95% of the time. Penetration testers still talk about it because they still find it after all these years.
Of course I have no reason to know this other than it being a potential question for a certification test I once took, but Microsoft stops supporting operating systems after about 10 years, and patches remain available for an indefinite amount of time after that, and after that indefinite period of time, Microsoft stops offering them. So, hypothetically speaking of course, if a company is running Windows 2000 today and didn’t have a copy of MS08-067 laying around, there’s no legitimate way to get a copy of it from Microsoft now. I’ve never had any reason to look, but I’m sure there are lots of illicit copies of it floating around still, but one must assume those copies are carrying around extra goodies as a little bonus. A company running Windows XP or 2003 probably could still download a copy of MS12-054 from Microsoft–don’t ask me why I know that particular patch also fixes MS08-067–but the window of opportunity is very limited at this point.
There are people who believe that Microsoft software is still inherently insecure, but that’s more marketing than reality at this point. Problems like MS08-067 used to appear on a regular basis, like, once a year or more, and I’ll admit I was as skeptical as anyone when Microsoft unveiled the Trustworthy Computing initiative. I was anti-Microsoft decades before being anti-Microsoft was cool–1989 or so–but Microsoft hasn’t found a comparable vulnerability in Windows since 2008. Getting the inside perspective from Microsoft on how they found MS08-067 and problems like it is valuable and interesting reading, because it’s a firsthand account of how a large company recognized it had a serious problem and how it solved it.
The transparency is commendable because it can help other companies solve similar problems.