Office SP3 and File formats

David LeBlanc's Web Log : Office SP3 and File formats

247Blogging — Wed, 21 May 2008 22:42:27 GMT

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

Updates to Office 2003 include changes made in Office 2003 Service Pack 3

Nick MacKechnie — Tue, 15 Apr 2008 06:17:49 GMT

As you may know, Office 2003 Service Pack 3 contains some changes to the behavior of Office . For example,

Microsoft admits we were draconian and fixes it

Noticias externas — Fri, 11 Jan 2008 13:37:21 GMT

Did you see the flurry of interest in this issue with Office 2003 sp3? Essentially sp3 blocks certain

re: Office SP3 and File formats

RickRussellTX — Fri, 11 Jan 2008 02:13:32 GMT

Thanks for the reply. A final bit I should have mentioned -- the thing that was most frustrating about this is the way it was slipstreamed into the update process. Even the big README file:

http://support.microsoft.com/?kbid=923618

doesn't mention it explicitly. It mentions that some files may not open, and refers you to :

http://support.microsoft.com/kb/941636/

which ALSO doesn't mention explicitly which file types are affected, except for Corel Draw. Finally, you follow a link at the bottom of that page and drill down to

http://support.microsoft.com/kb/938810/

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.

re: Office SP3 and File formats

RickRussellTX — Wed, 09 Jan 2008 03:56:02 GMT

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:\test\File.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.

Thanks for your insightful comments and input.

Office 2003 SP3でブロックされる旧形式、互換形式ファイルフォーマット有効化レジストリファイル公開

米田 Blog ( SQL Server MEMO ) — Wed, 09 Jan 2008 00:48:59 GMT

Office 2003 SP3でブロックされる旧形式、互換形式ファイルフォーマット有効化レジストリファイル公開

re: Office SP3 and File formats

AlaskaHome1959 — Tue, 08 Jan 2008 08:27:31 GMT

[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.

re: Office SP3 and File formats

TreborG2 — Mon, 07 Jan 2008 18:52:48 GMT

Disgusted as usual.

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.

[dcl] You're really seriously misunderstanding the problem. We're not executing legitimate code, macros or anything else. When things go wrong, it's an exploit.

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.

Office 2003 sp3 and the file blocking issue

MVPs — Sun, 06 Jan 2008 08:36:18 GMT

Whoa way to go MS. Official MS reg key downloads to help people with the file blocking issue with Office

Office 2003 sp3 and the file blocking issue

The Official Blog of the SBS "Diva" — Sun, 06 Jan 2008 08:20:53 GMT

Whoa way to go MS. Official MS reg key downloads to help people with the file blocking issue with Office