Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
Signed OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the &quot;Package Info&quot; section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from &quot;document.xml&quot;.<p>Here are the attacks, as I understand them:<p>1. OOXML doesn&#x27;t sign content-types.xml. It also doesn&#x27;t sign the literal contents of document.rels.xml, but rather appears to parse it and sign the values from the file. So: you can add arbitrary files to a signed OOXML bundle. That shouldn&#x27;t matter, because none of those new files will be referenced by &quot;document.xml&quot;, which is signed. But: there are files that Word will render without references, like &quot;people.xml&quot; (which describes the authors of a document); you can add that file after signing, and its content can take over the whole document render.<p>2. Document styles are stored in &quot;styles.xml&quot;. You can create an OOXML file without a &quot;styles.xml&quot;, sign it, and then later add an unsigned &quot;styles.xml&quot;; since the binding between &quot;document.xml&quot; and &quot;styles.xml&quot; is implicit and not cryptographically verified, if you&#x27;re clever about the original document you have signed, you can use styles to change the meaning of the document later.<p>3. There&#x27;s a tricky attack involving the interaction between .DOC and .DOCX that I don&#x27;t totally follow, but the gist is: you can get a benign .DOC signed, and then write a malicious .DOCX file, and scrape the signature from the .DOC into the .DOCX file, along with the contents of the .DOC. Signature verification will follow the contents of the .DOC, but the render will be of the .DOCX.<p>4. There&#x27;s apparently a nasty implementation bug where the verifier doesn&#x27;t check to make sure that the hashes in the signature manifest are related to the signature itself, but rather just that the hashes are valid. So you can take an XML signature from any other source (a SAML token, for instance) and splice it into a self-signed OOXML file, replacing the signature but not the hash manifest. Both will verify independently.<p>5. You can take any signed OOXML Excel spreadsheet and inject a malicious .DOCX into it. Then rename the file from &quot;.xlsx&quot; to &quot;.docx&quot;. Word will open it, prompt you to &quot;repair&quot; the file, and then render it as if it was signed.<p>The core issues here seem to be:<p>1. Never sign XML.<p>2. Never sign a file&#x2F;bundle format that gives you as much flexibility as OOXML does: being able to add and remove files after a signature was applied without invalidating that signature is the root of most of the attacks in the paper.<p>3. When you&#x27;re trying to do signatures over something as complicated as Microsoft Word documents, it&#x27;s not enough to have a coherent model for signing the structure of the file format --- which, it looks like, was the brief for the designers of OOXML signatures; your model needs to take into account the behavior of the whole program (&quot;people.xml&quot;, styles and &quot;styles.xml&quot;, &quot;document repair&quot;). You can imagine a team at Microsoft that understands how signatures work getting the assignment to design this feature, and coming up with it based only on the documentation for the file format, because Word itself is a beast, and who wants to spend a year figuring out how it works?<p>4. You have to test these things. Attack #4 is a table stakes vulnerability that could have been a unit test for how simple it is.