Affects: OpenOffice 2.3.0 and 2.2.0 and possibly older versions
I. Background OpenOffice is a opensource suite containing several programs to handle Office documents like text documents or spreadsheets. The latest version uses an XML based document format (ODF). OpenOffice allows documents to be digitally signed by authors using certified keys, allowing viewers to verify the integrity and the origin based on the author's public key. The author's public-key certificate, which can come from a trusted third party, is embedded in the signed document. II. Problem Description The digital signature and the certificates are stored in the ODF ZIP container in the file META-INF\documentsignatures.xml. OpenOffice does store the public-key certificate in X509 format in the XML file under META-INF\documentsignatures.xml. Additionally OpenOffice replicates all the information contained in the X509 formatted certificate in additional XML structures. For example the issuer's name is stored under document-signatures/Signature/KeyInfo/X509Data/_ X509IssuerSerial/X509IssuerName. This replicated data is not covered by the issuer's signature (of course), and it is also not covered by the document's digital signature. As a consequence, it can be changed without violating the integrity of the signed ODF document. The real problem arises from the fact that the replicated, unprotected data is used to build the first information dialog that a user gets after a double-clicking on the icon in the statusbar that indicates a valid signature or after choosing "File->Digital Signatures" from the menu. Only when he opens the certificate's details the correct and protected information is decoded and thus certified information is shown. Users are informed by a small symbol in the statusbar about a valid digital signature, and the first dialog box already informs them about the following: - name of signer - signer's certificate issuer (which induces the trust) - date of signature There is little incentive for an average user to go beyond this dialog and request more details, but the above mentioned "certificate details" are shown one dialog "deeper" than this. III. Impact An attacker can trick the user into believing that he got a certificate issued by a party that he did not receive the real certificate from. For example he could choose to pretend to be part of a more trusted organization. So an attacker can lead the user into believing that the signed document's contents are more trusted. III.1. Proof of Concept An attack works as follows: The attacker chooses a key for which he gets a certificate that can be automatically verified by the user (due to a chain to a trusted root). Then change the issuer's names that will be displayed in the first dialog to an arbitrary value. Take a signed ODT document, use a ZIP tool to get access to the ODT internal structure. Find the "CN=" entry in the XML element named "<X509IssuerName>" in the file META-INF\documentsignatures.xml. Substitute it with "FooBar". Save the xml file, close the ZIP container and reopen the ODT document. The issuer's name will display "FooBar" in the first dialog, and the signature remains valid. IV. Workaround Always use the view certificate button to view the information that was actually signed and store in the certificate. V. Solution No none solution. VI. Correction details OpenOffice's signature information dialog shall not use the replicated information. Or even better OpenOffice shall not replicate and store this information in the XML at all. VII. Time line 2007-10-24: Vendor contacted 2007-11-24: Deadline reached 2007-12-12: No response received until today Yours, Henrich C. Poehls, Dong Tran, Finn Petersen, Frederic Pscheid SVS - Dept. of Informatics - University of Hamburg
