Bugtraq mailing list archives

Security side-effects of Word fields


From: Alex Gantman <agantman () qualcomm com>
Date: 26 Aug 2002 21:23:22 -0000




I have stumbled onto a couple potential security issue in Microsoft Word.  In both cases the adversary (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 disabled 
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 achieve 
this, Alice embeds the INCLUDETEXT field into the document.  The field results in inclusion of a specified file into 
the current document.  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 usual things like hidden text, small white font, etc.  Alternatively (and in my opinion 
cleaner, she can embed the INCLUDETEXT field within 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 to import the file. 
 If the document is large and contains tables of contents, figures, etc. then Bob is very likely to update all the 
fields.  However, Alice would like to make sure that the field gets updated regardless of whether Bob does it manually 
or not.  Automatic 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" }  \* MERGEFORMAT  } = "" "" \* 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 
confirmation (via a dialog box) for all includes.  Alternatively one could write a scanner.  Of course an optional 
standalone checker will never 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 types 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 document.  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 filename.  Thus even though the sign contents remained the same, the 
displayed contents changed because they were partially dependent on unsigned inputs.  The basic point is that very few 
users know the actual contents of their Word documents and it should be obvious that one should never sign what one 
cannot read.  Of course, Bob could contest the contract in court.  An expert witness (that's actually an expert) could 
easily demonstrate that there are unsigned inputs and therefore it is not clear which version was actually signed.  
Thus Bob can get out of the fraudulent contract.  However, the same logic will hold for Alice and she gets away without 
paying Bob $100 she signed for.  Thus, an adversary can build in a free escape clause.  Note that I am just speculating 
about all the legal aspects.

Proof of concept:
Inserting the following field structure at the tail of the document will cause "Hello" to be displayed if the filename 
is "a.doc" and "Bye" otherwise.
{ IF { FILENAME  \* MERGEFORMAT { DATE } } = "a.doc" "Hello" "Bye" \* MERGEFORMAT }

Countermeasures:
Do not sign dynamic documents (i.e. know what you are signing). 


Current thread: