Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   Microsoft Word Vendors:   Microsoft
(Microsoft Responds) Microsoft Word Document Processing File Include Bug May Let Remote Users Obtain Files From a Target User's System
SecurityTracker Alert ID:  1005223
SecurityTracker URL:
CVE Reference:   CVE-2002-1143   (Links to External Site)
Updated:  Oct 17 2002
Original Entry Date:  Sep 16 2002
Impact:   Disclosure of system information, Disclosure of user information
Vendor Confirmed:  Yes  Exploit Included:  Yes  

Description:   A vulnerability was reported in Microsoft Word. A remote user may be able to obtain files from a target user's system.

A remote user can reportedly insert a specially crafted 'INCLUDETEXT' field in a document and send it to a remote user. If the target user then edits and saves the document, files specified by the INCLUDETEXT field and located on the target user's system may be automatically and silently included in the document. If this document is then returned to the remote user, the included files may be inadvertently disclosed to the remote user.

As a demonstration exploit, the following field structure can be inserted into the footer of the last page to steal the contents of the file 'c:\a.txt' on the target user's computer. Note that the plain curly braces represent Word field braces.

{ IF { INCLUDETEXT { IF { DATE } = { DATE } "c:\\a.txt" "c:\\a.txt" } \* MERGEFORMAT } = "" "" \* MERGEFORMAT }

Microsoft has stated that "the issue appears to affect all versions of Microsoft Word," according to an Associated Press report.

Impact:   A remote user may obtain files on a target user's computer if the target user will edit, save, and return a malicious Word document.
Solution:   No solution was available at the time of this entry. Microsoft is investigating the issue and plans to issue a fix.

Microsoft has noted that there are several (pre-existing) Microsoft Knowledgebase articles that address methoeds to ensure that a Word document does not contain additional undesired information, including how to inspect and remove field codes.

"WD97: How to Minimize Metadata in Microsoft Word Documents":;en-us;Q223790&sd=tech

"HOW TO: Minimize Metadata in Microsoft Word 2000 Documents":;en-us;Q237361&sd=tech

"HOW TO: Minimize Metadata in Microsoft Word 2002":;en-us;Q290945&sd=tech

Microsoft plans to provide fixes for all supported versions of Word. According to an Associated Press article, Microsoft will not repair Word 97 because it is no longer a supported product. Office 97 customers can (for a fee) obtain Office 97 assistance from Microsoft Product Support Services (PSS):

Vendor URL: (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Microsoft Issues Fix) Microsoft Word Document Processing File Include Bug May Let Remote Users Obtain Files From a Target User's System
The vendor has released a fix.
(Microsoft Issues Fix for Excel) Microsoft Word and Excel Document Processing File Include Bug May Let Remote Users Obtain Files From a Target User's System
The vendor has released a fix.

 Source Message Contents

Subject:  Security side-effects of Word fields

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 }

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

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 

Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC