Re: About File "types" and Office 12.1 Service Pack and double-clicking

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Hi Steve:

On 19/05/08 12:58 AM, in article 180520081128558864%maser@xxxxxxxxx, "Steve
Maser" <maser@xxxxxxxxx> wrote:

1) Why is the file type of "WDBN" not a security issue for Word 2004?

Completely different code running in Word 2004. There is almost NO code
re-used between Office 2004 and Office 208. In Word 2004, they have had ten
years to test that code against all manner of unlikely exploits.

But taking a wild guess here, I would say they have decided that it's not
worth spending the money to subject the Office 2008 code to the same level
of testing for exploits, in a file format that nobody is actually using.

Note: Just because the file contains a WDBN type code, does NOT mean the
file is actually in the old format. If Microsoft Word:Mac wrote the code,
then you know it's a Word 4, 5 or 6 file. But if some other application
wrote it, all you know is that it is NOT in the NEW format :-)

It's not (yet?) been made clear what the double-click-opening issue
with "WDBN" file types are that it only affects Office 2008, but not
2004. If this is an OOXML issue, will it (eventually?) hurt Office
2004 whenever the long-delayed translator for 2004 is released?

The OXML translator is basically the active ingredients of Office 2008 with
the user interface cut off. But I would guess "no", because the translator
becomes involved ONLY if the file type is OXML.

Nobody has said that there IS a security issue with the old file format.

This may seem counter-intuitive unless you have some experience in the
security software industry. I worked in the software testing department of
one of the world's larger banks, so I can make a few guesses...

I suspect that nobody has found any security issues with the old format
running with the new Office 2008 code base. I suppose it could be possible
that they have predicted a "theoretical" exposure. But it is more likely
that they simply "don't know".

Remember that when you are Microsoft and you are selling to the Defence
Department, "We do not think there is a problem" is not the right answer.
You have to be able to say "We can prove that there is no problem."

The cost of finding out for sure can be seriously high (We spent a month
with two highly-expensive specialist consultants, two test engineers and
four high-powered workstations, running a suite of penetration and attack
tests against a much, much smaller application than Microsoft Office).
We're talking about spending nearly half a million testing a relatively tiny
application: Microsoft Office is a "huge" application.

So as a wild guess, I would say that rather than jack up the price of
Microsoft Office to cover the cost of testing for any possible combination
of codes in every Microsoft Word format that has ever existed, they decided
to rule a line and say "We do not think this list of formats is still in
use, so rather than leave them hanging around where they may cause a problem
years in the future, we will simply disable them now."

This strategy dramatically reduces the "attack surface" an application
exposes. It means that no bad guy can come along years in the future and
use your application to fire "pinball attacks" around the system. A
"Pinball Attack" is where you bounce code off one application, causing it to
call another application, causing that to call yet another application, that
"might" have a vulnerability.

Pinball attacks are almost impossible to test for, because the
application(s) in the middle may not even exist yet.

2) If the argument is that certain web browsers/mail programs are
doing things "wrong" about putting "old" file types on
downloaded/decoded attachments and should be leaving this *blank* and
relying on "extension" only (rather than updating for a more current
file type)...

I don't think that's the argument. I think the argument is that an external
applications should either write the correct type code into the file, or
leave it unchanged if it does not know what the type code should be.

If the file type is blank, Word will assume the extension is correct and try
that.

Then why does Word 12.1:

A) Allow me to save/edit/open a word document with no extension,
without throwing up a red stop sign?

It won't. When you ask Word to open a file, it scans the file internally,
looking for type information. As well as the file type and creator code,
there are two other indicators that I know of, plus two more if the file is
in XML. This information is stored in ANSI text in the first 500 bytes of
the data fork of the file.

If Word finds a type it knows about in there, it will try to interpret the
file content using the converter with its parameters set for that file type.
If the result doesn't make sense, THEN it will go red in the face and spit
the dummy on you.

B) Still put a "W8BN" file type on documents it saves? If they
want to lead by example, why is this not blank as well (a type is added
if I save the document with or withouth an extension.)

W8BN is a valid type. It indicates that the file content is expressed in
16-bit Unicode (as opposed to 8-bit ANSI).

C) Not allow "extensions" to override file types? -- Which would
resolve the problem (likely) for the vast amount of users.
(Admittedly, I can see why this might be considered a bad idea, but...)

Again, you are assuming that Word is making this decision. I do not think
it is. I believe the decision is being made by Apple OS X in the Launch
Services module. It sees the old type code and thinks "I don't know where
to send that, none of my applications have declared any interest in that."

If you use File>Open, Word can then look inside the file and say "Ah hah! I
know what this is..."

Why is there not internal logic in the program that says something like
"well, it's "WDBN", but it has a ".doc" extension, so we'll open it
anyway...")

There is. But the call from the Finder from a double-click never gets that
far. The Finder sends it to Launch Services, and Launch Services says
"Dunno". Word never comes into play.

I would surmise "B" is being done because "A" is allowed. But,
according to the MVPs defending this results of applying the 12.1
service pack, neither "A" nor "B" should be done. "Extensions only"
from this point on to open files via double-click, right? :-/

Which MVP said that? I didn't see that? However it does sorta tend to be a
Unix convention :-) Not using file extensions is a silly idea that came in
from Windows. Windows files do not have a resource fork to tell the OS what
kind of data the file contains: the extension is supposed to do that.

Some idiot decided that that was all too hard for the poor little users, and
created a module in Windows that reads the front of the file and tries to
"guess" what it is if there is no extension.

So, of course Mac had to copy that.

Then the bad guys started playing around with the file extensions, lying
about what was in their files. So Microsoft and Apple and a few other
vendors started to treat the file extension as "suspect" and look inside to
see what was really there.

But if we want to be good Unix citizens, we EITHER put an extension on the
file, OR the content is assumed to be ANSI plain text with Unix line-enders
:-)

Cheers

--

Don't wait for your answer, click here: http://www.word.mvps.org/

Please reply in the group. Please do NOT email me unless I ask you to.

John McGhie, Microsoft MVP, Word and Word:Mac
Nhulunbuy, NT, Australia. mailto:john@xxxxxxxxxxx

.



Relevant Pages

  • Re: Extensions .docx & .docx.cpgz
    ... We have been receiving .docx ... reverted to the old IE we had been using - somehow in the reverting Microsoft ... Did Microsoft create the change from XML-based format to .docs, ... From a friend that uses a PC, I received an attachment that has the extension ...
    (microsoft.public.mac.office.entourage)
  • Re: Extensions .docx & .docx.cpgz
    ... format converrter and open the attachment. ... Did Microsoft create the change from XML-based format to .docs, ... From a friend that uses a PC, I received an attachment that has the extension ...
    (microsoft.public.mac.office.entourage)
  • Re: Extensions .docx & .docx.cpgz
    ... Did Microsoft create the change from XML-based format to .docs, ... ..doc files if they choose, but it takes one more step than saving as .docx, ... much less what the extension is. ...
    (microsoft.public.mac.office.entourage)
  • Re: text to bibliography?
    ... Help files are perfectly searchable nowadays. ... It is most certainly not coined by Microsoft. ... Once you start adding delimeters, you can just as well use ... However, to automate the entire process, the input format has to be ...
    (microsoft.public.word.docmanagement)
  • Re: text to bibliography?
    ... It is most certainly not coined by Microsoft. ... convert to the "format" used by the bibliographic database: ... Once you start adding delimeters, you can just as well use ... I've put tabs between the fields, in order to do Text to Table? ...
    (microsoft.public.word.docmanagement)