Mac Forum / Applications / Word / May 2008

Steve, what is the point of asking these questions in this forum?  To
argue that MVPs (which includes me) are wrong to not get all heated up
about it?

Feel free to tell MS their logic is inconsistent by using Help | Send
Feedback in any office app.

Daiya

Hi Steve,

Some misinterpretation messed up your logic--

No, that's not the argument. The argument is that email/browers should
not apply old file types. I don't think anyone said that browsers/email
clients ought to leave file type blank, or that file types should no
longer be used, or that only extensions ought to be important from now
on.  (Feel free to prove me wrong with a link)

Daiya

I'm personally finding this a very interesting discussion. I can't
answer all your questions and Word is not my forté. I'm sharing my
observations not as an MVP but as someone who does technical support for
a living.

I suspect this move in 12.1.0 is one of many predecessors to the return
of VBA, which was recently announced. They've removed WDBN, which means
they don't want others taking advantage of that file type and allowing a
malicious file to launch Word.

Who knows? We may see that changed too in an update. But I doubt it. We
have to keep in mind Microsoft's support life-cycle.

Office 2004 is marketed as a product that will work on Mac OS X 10.2.8
(IIRC) and higher. That means it still needs to work for older versions
of the Mac OS where file type and creator are more important.

Office 2008, however, is supported only on 10.4.9 and higher. Office
2008 can begin closing old security issues, which have probably been
around for quite a while. I suspect this is one of them. And Apple has
long been promising that file type and creator codes would be going
away. I see this move as housekeeping and a predecessor for more to come.

Again, I suspect this move is in preparation for something farther in
the future. And we should expect more. No idea on the Office 2004
converters patch.

I think you can assume something like this is coming. When? I don't know.

Probably coming too. Although Apple deprecated file type and creator
codes some time ago, they still haven't removed support for them. Until
that happens then Microsoft should leave this support.

However, in the meantime, Microsoft should certainly do everything it
can to move its users away from what's deprecated and into what will be
supported. We're in a transition period. I wouldn't expect everything to
move quickly. They'll certainly want to make this as painless as possible.

Deciding which application opens which file is the Finder's
responsibility. Word can't incorporate this logic. I believe that by
default the Finder *still* uses type and creator codes before file
extensions. That's an Apple decision and I suspect they have a time
frame for changing this behavior.

So, just to restate my thoughts:

1. Expect more and similar changes.
2. Expect a *transition* and not a sudden change in behavior.
3. Expect that this is for the long term.

Hi Steve:

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

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 :-)

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.

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.

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.

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

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

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.

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