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

[ reply ]