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