Office SP3 and File formats

In Office 2007, we changed the default to disable a number of older file formats where we saw very low usage and a high security risk in our code that loads these formats. From the security standpoint, this is the right thing to do. From the data we have on file opens, very few users open files in these formats, so we decided to modify the default behavior to this safer approach.

Attack surface reduction is something we spend a lot of energy on – the canonical example is IIS 5.0 vs. IIS 6.0. IIS 5.0 had enabled everything by default. Who's ever actually printed to a web server? OTOH, who's ever taken over a web server with the .printer exploit? Unfortunately, quite a few. Figuring out how to turn off the things that you don't need was too hard for most admins. IIS 6.0 took the opposite approach – turn almost everything off, and make it easy to turn on what you need. The security record of IIS 6.0 shows how effective this has been – they went from having a poor security record to one of the best.

We've been doing some of the same things with Office – there are converters that didn't get installed by default in Office 2003. We noticed that the attackers seemed to be preferentially hitting the parsers for the older formats, and if the great majority of you don't need the older format, its risk without reward. This was the thinking behind disabling the older formats by default in Office 2007 and eventually Office 2003 SP3. We'll try harder to make enabling older formats much more user-friendly in the future.

To put things in perspective, many of these formats are very old, with some dating back over 15 years since the app that created them by default shipped. Something I want to be very clear about – we are not removing your ability to read these files. If you need them, the parsers are still there. All we've changed is the default. The older formats are still supported. We understand that some of you have a need to be able to read archived files, sometimes for long periods, and we will continue to support that. There are two ways to continue to open these files:

You can create a trusted location and place the files there. This is documented in http://support.microsoft.com/kb/922849. It's an easier process if you're running Office 2007 than if you're on Office 2003, but it is an available option.

You can change the default version that we'll still open, which is discussed in more detail below.

Recently we released SP3 for Office 2003, and we took a number of the security improvements for Office 2007 and applied those to Office 2003 as well. Unfortunately, we make a couple of mistakes that we will correct immediately.

We did a poor job of describing the default format changes. There is a KB article for it here - http://support.microsoft.com/kb/938810. In the KB article we stated that it was the file formats that were insecure, but this is actually not correct. A file format (with some exceptions, like .hlp files) isn't insecure – it's the code that reads the format that's more or less secure. The parsers we use for these older formats aren't as robust as the code we've written more recently, which is part of our decision to disable them by default. But again, it isn't the format that's the problem, nor is it the app that wrote the format – it's the app that reads the format. We just revised the KB article to correct this error.

Some of the formats blocked are from products built by companies other than Microsoft, and we apologize for implying that there were any problems in those companies file formats.

We did not provide an easy way for end users to change this behavior so they could open these older files. There are admin templates that system administrators can easily use, and there are also some registry keys that people can set, but that was it. In order to make this easier for anyone to override, we'll update the KB article and provide the following files that anyone can download and run to override the security settings.

The .reg files you can use to change the security settings can be downloaded here:

In order to change the settings for the CDR file type, you need to be logged on as an administrator, or if you're on Windows Vista, running with an elevated application. By default, regedit will prompt for elevation when it runs the .reg files. This is because the filters used to import some older image formats like CorelDraw CDR files is registered in the machine-wide settings, not the per-user settings.

In closing, I want to emphasize that we're not removing support – we're making the default safer. If you're among the users who do need to be opening these formats, we will continue to support you. We also recognize that we have not made any of this as usable as we'd like, and we apologize that this hasn't been as well documented or as easy as you need it to be. We're also going to take a hard look at how we can do better in the future.

I’m sorry, but I’m afraid that Microsoft simply lacks credibility when it says “sorry we removed support for old formats solely because we wish to reduce the ‘attack surface’ of our software”.

[snip – fnord]

[dcl] I can tell you’re the kind of guy who really likes conspiracy theories, but tell you what – go to http://www.microsoft.com/technet/security/current.aspx and do a search on bulletins that apply to Office 2003, SP2 and later. I get 25 of them, with more coming. That’s way too many. There’s no way we’d ever even consider doing something like this if we weren’t trying to solve a serious problem that was affecting a lot of customers. As I said, we didn’t do it as well as we should have, and we’re apologizing for that. I’m not apologizing for protecting customers from active threats. We’ll learn from this, and we’ll do it better in the future.

PS – we didn’t remove support. The formats are all still supported, they’re just off by default.

So disable access to the files, when the REAL problem is that you should correctly disable macro’s and other functions when opening documents so that any malicious code in them can not execute without explicit user permissions!

[dcl] You’re misunderstanding. When you’re attacked with a malicious file, it doesn’t need any macros to do bad stuff. We are correctly disabling macros – not the problem.

I completely understand the need to block the bad things that can be done by the various files and older formats … the problem however isn’t the files .. it is the program that OPENS the files that is the real issue.

[dcl] Right – and that’s what I said more than once in the post.

And for every day you don’t fix the program that OPENs a file, you only grant crackers another day to find ways to circumvent any of the external methods you’ve used.

[dcl] “Crackers” are different than hackers and attackers. Crackers break copy protection and games. There’s a couple of points here – first is that if someone can only attack a fraction of the users, they’ll go find a broader attack. If the attack depends on attacking a Word 1.2 parser, and it’s not on by default, they have to go find something else – which is harder.

Tell me, does this stop the code from executing? Or does it merely attempt to not allow to be loaded any file that might contain the bad code?

[dcl] Yes, it does stop the code from executing _by default_.

What’s to stop a cracker (and I’m sure they have tried already) from forging the type of document, to get it to open, but reference code and flaws that exist in the versions of files that you wanted to prevent the execution of?

[dcl] The load will fail – things won’t be where they’re supposed to be, and the file won’t open.

If your opening routines are dumb enough to execute **ANY** code inside a file, then they are dumb enough to be tricked with some form of version labels changes/tricks.

Fix the f**king software, not the documents that its supposed to open, and stop assuming that you know everything about how people use their computers, or what they will need to do 6 months or 6 years after a version of some file is out.. I’ve got documents from 10 years ago, that I might be requested to open at some point in time.. YOU don’t know that.. so why do you presume to think there aren’t valid needs?

[dcl] Actually, we do know a lot about how people use Office, IFF you opt in (_your_ choice) to the customer feeback program. An extremely small fraction of all users ever open these files. All users are open to attack. I have some of these older files myself, but I don’t have a need to open them any more – ought to clean those up. It’s like this – we only had so much time to work on SP3. Wouldn’t you rather we make something you _have_ to use, like Office 2000-2003 formats, secure? If we’d spent more time on say the Word 2.0 parser, we’d have spent less time on the things you have to have. Ideally, I’d like it if anything we shipped was to the same security level, and I hope we’ll get there.

Upon opening a file, regardless of security, anything perceived as insecure should be offered as a series of prompts and checks …

[dcl] There’s a lot of problems with this. It’s hard to tell people what’s going on so they make the right choices. Some worms use ridiculous amounts of social engineering.

a REAL solution, would be to allow step-by-step execution of code, so that people could see what was supposed to happen, or be prompted for it, and at least have the potential to know what is going to happen.

[dcl] This is based on your misunderstanding above, and sorry – it would only help serious devs, who are probably fewer in number than the people who open really old files.

Or have a “kill” button so that should something be happening a user could KILL the program immediately and any application it spawned.. or.. like someone else offered.. a sandbox environment..

[dcl] Nope – too late – by the time malware has run, your system (especially without LUA and UAC) isn’t your system any more.

For all of your intelligence, Microsoft, you sometimes do *THE* most stupid things in the world..

[dcl] It’s a company made up of people. People make mistakes, and in hindsight, mistakes usually look dumb. I sometimes joke that if we really were the evil empire, we’d be much better organized.

[dcl] Some editing here – the commenter is rude, but worth addressing – I said:

“The parsers we use for these older formats aren’t as robust as the code we’ve written more recently, which is part of our decision to disable them by default.”

This is MicroSpeak for ‘Our conversion filters are [not robust].

[dcl] I thought it was plain English for “they’re not secure”, which is only one part of a parser we care about. It also needs to correctly render the format, which it does well enough, and they seem to have reasonable performance characteristics, and they also deal with non-malicious inputs well enough.

They have always been [not robust].

[dcl] Well, yeah – we sure didn’t go and make them _worse_.

We don’t care that they are [not robust]. We can’t be bothered to fix them because we can’t be bothered to waste our time fixing [not robust code].

[dcl] This is where you’re just being rude – and you’re wrong. We do care about the security of all the code. The problem that you hit when you’re doing this for real, as opposed to arm-chair quarterbacking, is that you have a time-features trade-off. We _could_ have fixed the code, at some risk of creating rendering regressions. It also would have either meant making code that more people use get less attention, or it would have meant slipping the schedule, which leaves customers open to attack for a longer period of time. It’s called triage.

[dcl] There’s no one here that thinks any of this is an easy trade-off, and we very much care about every aspect of code quality. Given that customers _are_ under attack, we made a decision to get the service pack out as quickly as we could, as it seemed most important to protect the great majority of the customers. I don’t like asking ANY customer to make a decision whether to take a security risk or backwards compatability, but we’re clearly not living in an ideal world.

[snip]

Okay, sarcasm aside, the proper ‘customer service’ oriented solution would be to fix the code, not cut off users from their files.

[dcl] Not entirely – would it have been better customer service to hold up the service pack for another 6 months, and allow 99.9+% of the customers to stay under attack while we worked on code that the rest of them need? If you look at the trade-offs, IMHO, we did the right thing. We’ll do better in the future.

[dcl] PS – please try to be polite in public. Your main point of “why didn’t you just fix the older parsers?” didn’t need expletives to get the point across. You’re speaking to a person here. It’s also in your self-interest – employers do use web searches to help make hiring decisions. Wag more. Bark less.

Mr. LeBlanc, with respect, some institutions depend critically on opening older files, particularly files that were created with earlier versions of Microsoft Office. Microsoft’s own product.

I realize that, as a total fraction of “office files opened by users”, file formats like PowerPoint 4.0 and Word 95 are a small fraction. Of course they are; the formats are ten years old. But for the affected organizations, it’s a stop-work problem that generates a service call unless they apply these registry keys across the entire enterprise.

You’re basically giving us two choices:

(1) disable MS Office features that we currently use and need, or

(2) expose our employees and the corporate network infrastructure to known and unknown security risks.

It would be fair to say that many companies have invested and re-invested in MS Office precisely because it offered seamless compatibility for the corporate storehouse of knowledge, going back to the late 1980s. That compatibility is *why we keep using it*.

I understand your argument that fixing the file format parsers could introduce rendering issues for those file formats, and that it will require effort that will affect product delivery timetables. Those are legitimate concerns.

But if you’ll pardon a cynical statement, it seems like MS is taking the path that requires the least work. You say, “We’ll do better in the future.” Does that mean you’ll fix the code and re-enable safe access to files created with Microsoft products?

FYI, I tried using the tools in the OMPM to bulk-convert old files up to Office 2007. The tool just doesn’t work. Numerous files — files that Office 2003 can open just fine if you apply the reg keys — failed with “Error: C:testFile.doc failed to convert”

So, we’ve got a lot of old files out there. We don’t want to expose ourselves to malicious code. What options do we have?

[dcl] I very much take your point. This isn’t the sort of trade-off we want to confront anyone with. The trade-off we were dealing with was how we could get the SP3 fixes to you as quickly as we could. The decision wasn’t so much about what was the least work as how we could get you protected as quickly as possible. I understand how it might appear to someone outside that we’re just trying to do the least work, but if you knew just how much work we did, it would put things in perspective. We took a lot more change in this service pack than we typically do in order to try to keep customers secure. So far, it looks like it is paying off – at least on the security side.

The points you’re making are very much part of our discussions about what we’re going to do going forward. As to exactly what we’ll do, we’re discussing it now, and I can’t speak here about something that isn’t either shipping or close to it.

If you’re having issues with the bulk converter, please open a support incident, and we’ll try to find a solution for you.

which is explicitly. That’s three articles you have to drill down through to find it.

Our security people are super responsible and I’m sure they read the full readme file and several of the referenced articles. But even I can’t blame them for missing this one.

Since you’re still working on it and ostensibly open to suggestions, allow me to suggest:

If you’re going to roll an update that retracts a feature, simply make it a separate non-critical update (mark it important, or something, since after all it’s not like it’s anywhere near as bad as MS08-001 or something like that).

System admins could decide for themselves whether to apply it via their internal WSUS process, or end users could apply it separately via Windows Update.

Rick R.

[dcl] That was one of the parts of this we really didn’t do well. If we’re going to change something like this, we _really_ need to tell you up front what’s going to happen. You’re right – that’s not an acceptable experience.

We have an easier time adding things by an additional update (MOICE is an example) than deprecating things. What I think we should have done was make it much easier for the user to roll back the change to the oldest version they need to deal with, especially in the case of Word, which can be very granular about it. Next thing is to make some real UI so that you can access the settings easily. At any rate, this is something we’re going to be working on going forward – in fact, just came from a very short meeting about part of it. Once there’s something I can talk about in public (which could be a while), I’ll post about it.

In Office 2007, we changed the default to disable a number of older file formats where we saw very low usage and a high security risk in our code that loads these formats. From the security standpoint, this is the right thing to do. From the data we hav

keep reading about the registry fix “unblockexcel.reg”but I have no luck at finding it. I realy need it. I found a regedit fix for windows 7 but I can’t find one I feel trustworthy since I installed Windows 10 but no luck yet.