Home / vulnerabilities openoffice-signature.txt
Posted on 14 December 2007
Source : packetstormsecurity.org Link
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-INFdocumentsignatures.xml.
OpenOffice does store the public-key certificate in X509 format
in the XML file under META-INFdocumentsignatures.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-INFdocumentsignatures.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
