We’ve just released SP3 for Office 2003, and it’s been a lot of work. We’re releasing a bit more in this service release than we normally do, but this is part of our response to the current security environment. I joined Office at the very start of the Office 2007 development process, and one of the first themes to emerge was an increased focus on fuzzing our file formats. We then proceeded to do a lot of great work in this area – properly fuzzing Office documents can be difficult. Many of the teams built fuzzers that target their file formats directly and at a low level. We used the infrastructure provided by SWI (Secure Windows Initiative), but the interesting parts were usually very Office-specific. As we moved forward, our approaches and techniques became more sophisticated, which is something we’ll continue.
As we accumulated a larger and larger library of files that caused crashes in our applications which were fixed in Office 2007, we recognized that we needed to be able to deliver fixes for these same issues to customers running Office 2003. The magnitude of the change, and our commitment to ensuring updates are reliable demanded that we use a service release as a ship vehicle – it’s the only way we could do all the necessary testing. We then subjected Office 2003 to the same level of fuzz attacks that we used against Office 2007 – and then some – we’ve gotten a little smarter about fuzz testing in the last year – and then fixed what we found.
You might wonder why we’re just now focusing security efforts on Office 2003 – didn’t we think about security when we shipped it? In fact, we thought a lot about security when we originally created it. Office 2003 was the first version to go through a security push, and when the first version of the SDL was released just after we shipped, we found that we met or exceeded (sometimes substantially exceeded) the requirements of the initial SDL. My friend Michael Howard has written about how important it is that Vista has removed the unsafe string handling calls and annotated functions with SAL (standard annotation language) – that’s a lot of work, and it has great results. We’d already done that in Office 2003, and the very low regression rate Office experienced in removing the older string handling APIs was a lot of what helped Windows to do the same thing. When Office 2003 shipped, we thought we’d done some good work and that it would be a secure product. For the first 2 years after release, it held up really well – only 2 bulletins. Then people shifted their tactics and started finding problems in fairly large numbers. I can’t gloss this over – you can look up the security bulletins that apply to Office 2003 yourself.
What explains this change? I think the first change is that the focus of attacks across the board (independent of operating system choice) has moved to the higher layers. For example, when I was involved in operational network security, if I wanted to get into a web server, I’d attack the OS or the web server directly. Why bother with SQL injection when I can take over the whole server? These days a pen tester who doesn’t know the ins and outs of SQL injection isn’t a very good one, since it’s not usually very easy to just take over the server. This moves the attack surface for many networks to the desktop, and where better to attack than widely deployed applications?
A second trend has been an increasing shift towards attackers operating for financial gain. Back in the good old days, people would take over systems and not disturb them since they might have just wanted to use the computer, and not install bots or spyware. You might trade exploits like baseball cards, and the guy with the coolest exploits got their ego stroked, but there wasn’t much of a financial incentive. That’s changed – there’s a real financial incentive and a real underground (sometimes not very far underground) trade in exploits.
In response to all of these changes, there’s been some very serious investigation into fuzz testing on all sides of the problem. We did do a great job with Office 2003 – against the attacker techniques that were in use in 2003. As it turned out, it didn’t do as well against the attacker techniques in use in 2006. What this tells me is that we have to keep moving – every time we raise the bar and make things harder on the attackers, they’ll work harder too. We have to think about how we keep products serviced in the field – though we’d like it if you all rushed out and upgraded instantly, we know from our user data that most of you are more conservative about change than that. The work we’ve done in SP3 is recognition of our need to keep products in the field protected against current threats.
Why should you move to Office 2007 if Office 2003 + SP3 is so robust? I have to be clear that there are some things we just can’t do in a service pack. For example, the compiler we used for Office 2003 was shipped in Visual Studio 7.1, and the compiler we used for Office 2007 was the compiler used in Visual Studio 2005. As I documented in “Writing Secure Code for Windows Vista”, there are mitigations in the new compiler that stop certain attacks cold, and the older compiler doesn’t do as well – again, it was very effective when it shipped, but everyone keeps moving forward. We wanted to get you this update as quickly as we could and make it as robust as possible.
I’m not as brave (you may have other words for this) as Michael Howard, and I’m not going to predict how much reduction in bulletins there will be as a result of SP3, but my hope is that it will be very substantial – the only thing I’m sure about is that change is the only constant. Our preliminary indications based on incoming MSRC cases is that this work has been very effective. We’ve done a lot of work to make your day to day use of our products more secure, and you can be sure we’ll keep working in that direction.