Disclosure: I work for Microsoft, but not for the team in question. So the following is based on speculation.

The problem with binary files is detecting whether or not they are malformed, causing crashes and thus a vector for running bad code. One way to protect against this is to validate the file, examining the file's contents and ensuring that it's all comprehensible. In Office's case, the best validator available would be the Office 2007 OOXML converter, since that is intended to support *every* feature in the 2003 file formats. If a file converts successfully without errors, then we can assume that the file is safe.

Furthermore, running the validator needs to happen in a separate process, to ensure that crashes occur in a process that doesn't have any access to any other data.

Opening a malformed file on a Mac is less of an issue because even if it causes a crash, the bad code won't run because they're most likely aimed at the x86 architecture. (Remember that Mac Office 2004 is written for PowerPC; there is no Universal version yet.)

There's no indication that these files end up being *saved* in the OOXML format, thus propagating the format.

A wrote: "The problem with binary files is detecting whether or not they are malformed..."

Well articulated and rationale response.

I wish your company could have provided a spokesperson to also offer perspective.

Thanks,

Joe

"I wish your company could have provided a spokesperson to also offer perspective."

According to you, they offered to. You simply declined because it didn't meet with your deadline.

Paul wrote: According to you, they offered to. You simply declined because it didn't meet with your deadline.

You are wrong Paul. The next to the last paragraphs states:

Microsoft could not immediately provide a spokesperson to discuss MOICE; we declined opportunity to e-mail questions and receive anonymous spokesperson responses, contending it wouldn't be in Microsoft's best interests. Microsoft then chose not to comment.

Also note that Microsoft declined to comment when Joe wanted someone to go on the record.

I agree with Joe's comment about A's response being 'articulated and rationale'.

But, it's a sad commentary when an employee needs to post anonymously to support the company they work for.

A wrote:

The problem with binary files is detecting whether or not they are malformed, causing crashes and thus a vector for running bad code.

Bullshit. Malformed textual formats (such as XML and HTML) are just as capable of causing crashes, if the reader code is not well written. It's not the formats that are vulnerable to crashes, it's the code. Fix the code and you stop the crashes.

Phish, you can't read. An "anonymous" spokesperson was offered via email (though how anonymous those would have been is TBD). It was Joe who declined. Bottom line, if he wanted a direct official response from MSFT, one was offered albeit not necessarily on his timeline or in the format of his choosing. Go figure. And btw, I'm not an employee. So there's two strikes.

Come on people and look at where the threats are coming from and we as IT Managers CAN'T shut off the word/excel attachments and we can't train our employees to not click worth a darn.

So maybe some folks are considering this as an additional mitigation factor.

Until you download it and TRY IT OUT how about report on the facts of this and not the speculation.

I'm struggling to understand this. I make the following two assumptions:

Office files contain data
Office applications interpret/manipulate this data

So how is it possible that a MS Office file can contain malicious software? This is only possible if the Office Applications themselves are unable to interpret their own proprietory files. According to MS, they are unable to do this to the extent that it is a real security risk.

It then follows that it doesn't matter what form the data is in - it is the Office applications that are the security risk as they are unable to interpet their own data files safely.

This raises too many questions for me - all with answers that reflect extremely poorly on MS.

Alternativley, and to keep this as brief as possible, lets say that the Office applications can interpret their proprietory data files - how then are the Office applications able to perform malicious actions? Once again - all answers reflect extremely poorly on MS.

I'm struggling to understand this. I make the following two assumptions:

Office files contain data
Office applications interpret/manipulate this data

So how is it possible that a MS Office file can contain malicious software? This is only possible if the Office Applications themselves are unable to interpret their own proprietory files. According to MS, they are unable to do this to the extent that it is a real security risk.

It then follows that it doesn't matter what form the data is in - it is the Office applications that are the security risk as they are unable to interpet their own data files safely.

This raises too many questions for me - all with answers that reflect extremely poorly on MS.

Alternativley, and to keep this as brief as possible, lets say that the Office applications can interpret their proprietory data files - how then are the Office applications able to perform malicious actions? Once again - all answers reflect extremely poorly on MS.

Lawrence wrote:
Bullshit. Malformed textual formats (such as XML and HTML) are just as capable of causing crashes, if the reader code is not well written. It's not the formats that are vulnerable to crashes, it's the code. Fix the code and you stop the crashes.

You're correct that a malformed XML/HTML file could cause a crash if the reader code is poorly written, and I meant to point that out; indeed, the Microsoft reader code could be vulnerable that way as well. But because an XML file provides better uniform structure, it should be (theoretically) easier to write a correct reader that guards against such malforms.

But you're wrong that a format itself might not lend itself to enabling vulnerabilities. Having never examined the binary Office formats, I can only imagine that they conceived of attacks via Office documents where validation is lacking; it would not surprise me if the MOICE fix came about as a result of the ANI cursor issue (where the cursor file was inadequately validated).

HMS: It seems like you've figured out what the answers are, so there's no point in my answering your questions. But you're right, we could've and should've done better.

Nevertheless, there appears to be a misunderstanding on your part -- a malformed file wouldn't cause an office application to behave maliciously, but instead use the app to give the file an opportunity to execute its payload. Do an internet search for "buffer overrun" for more details.

So Joe, now that you have received a "Well articulated and rationale response" are you going to edit your article to something less hysterical?

Let's face it, ill-informed rants don't serve to help your readers and certainly don't do your reputation any good...

Ed wrote: "So Joe, now that you have received a "Well articulated and rationale response" are you going to edit your article to something less hysterical?"

No, Ed.

The post isn't hysterical, and the response I praised (for lacking an official one from Microsoft) didn't address the format topic.

Thanks,

Joe

The open file format is absolutely open. You can take the specification and use it to develop an application that consumes the file. Granted there are some backwards compatibility features that aren't open, but they are also not relevant unless the format is being used to perserve old documents.

Stop spreading FOSS fud. The ODF file formant is a disaster. Could you take the ODF specification and build a spread sheet application just on it?

It's not clear to me what else you're asking, Joe. The thrust of your post is that Microsoft is trying to force adoption of OOXML under the guise of security, and that "Microsoft might gain more cooperation by better respecting customers' intelligence and saying straight its objective. There's no need to use security concerns as a way of isolating and converting Office files."

In other words, you're accusing my company concocting some bogus scheme in order to further some other objective.

And for all I know -- that might be the case. But the purpose of my response was to explain that there was a perfectly reasonable explanation for why it implemented the isolation environment with an OOXML converter, that we're not lying to our customers. Yes, one could've conceivably implemented the isolation environment some other way; but that other way might've taken more time/resources.

It's not even clear to me what you mean by saying that OOXML is XML-based, as opposed to an XML file format. What qualities make ODF an XML file format and not XML-based? In my opinion, if you can point an XML parser to a file, and it can extract the tags and attributes, then that file is XML. Now, it's true that OOXML files are zip files that contain constituent files for the content; but the textual content of those files should be understood by an XML parser. So other than that -- what's the distinction?

Paul:

Why would anyone want to build an application on the ODF specifications?

You build applications to solve problems, to speed up processes, to reduce workloads.

And as such, you build them around good specifications based on the workflow involved, the problems to be solved, and the computing hardware/software resources available to you.

Building any application from file-specificatrion upwards is a ludicrous proposition. It's approaching the problem from the wrong end entirely.

ODF, as a vendor-neutral specification, is something you'd put into an application to provide interoperability with other applications. How your application works is irrelevant. Its user interface, its methds of working, even the platform it runs on - not an issue.

And open standards like ODF are what enable that to not be an issue, by enabling open data interchange between your program and other programs.

If you want, you can make ODF your native data store. But you can just as easily make it an Import/Export format, and for many applications that would probably be a better option.

ODF isn't about specifying an application's behaviour - it's just about having a well defined and common format for storing documents for word processing, spreadsheets, presentations and vector drawings.

Still, if you want to mingle the data layer and application layer into one big mess, you're welcome to. I just hope you're not a programmer - or worse, a technical architect. Because you're making a classic mistake that people in those kinds of jobs should be able to avoid...

Every file format defines an executable. Whether the result is interpretation of what looks like BASIC or a picture or a spreadsheet, all are executed by another application. Some will suggest that they are interpreted, but that only makes a difference if the worry is a machine-code level failure. Otherwise, the environment of machine and application are a virtual processor of the relevant code.

As a result, the concept of security is more about how much the application is tested and how well it is written than the file format.

The ZIP format certainly can offer a vector as can embedding pointer descriptors. Besides, most computer formats are ultimately binary. The fact that there are many interpreters that can read ASCII or unicode files and present them on the screen doesn't make those logic zeros and ones go away. Try stripping the first bit off a text file and see what you can read one character at a time from there.

Funny idea that MS OOXML is open except for backwards compatible features, considering format preservation is supposed to be the sole reason for making it an ISO standard.

I would guess that when the ODF spreadsheet component is approved then it will be easier to create an application that works with it.