I had commented
on the Black Hat 2009 OOo Security Paper some time ago.
There have been some points which could be clarified directly, or
where I didn't agree on, but there also have been some valid points,
where I promised that we would try to address them in OOo 3.2 –
what we did.
Issues listed in the article, where improvements to OOo had
Issue: Encrypted documents - Macros can be added, replaced or
Update: In OOo 3.2, you can't anymore add unencrypted macro
streams, or replaces existing streams with different (unencrypted)
For compatibility reasons, this check is only done for ODF 1.2
documents written with OOo 3.0 or newer. But OOo won't rely on the
ODF version listed in manifest.xml alone, and will also check the
version listed in the encrypted content.xml, so people manipulating the document can't circumvent
the check by manipulating (downgrading) the ODF version in
You still can remove all macros streams together, because we still can't protect
manifest.xml. Fixing this would need further enhancements to ODF,
since we don't want to create an OOo only solution, which would
result in OOo complaining about all encrypted documents written with
Another thing is that you can add encrypted macro streams, but
this won't have any effect. The reason is that macro streams can have
different encryption keys, because the user can give each basic
library an other password. But adding encrypted macro streams doesn't
matter, because OOo wouldn't be able to decrypt them, and they also
can't be registered in the basic library, because that file is also
To resolve the remaining (and probably minor) issue that macro
streams can be removed in encrypted documents, different options need
to be evaluated very carefully: This can be the protection of the
manifest.xml via some signature algorithm, or the encryption of the
complete ODF zip stream. That later solution could also be wrapped in
an ODF container, so you have a mimetime stream for better system
integration, and a place where you can document which encryption algorithms have been used.
Explaining these options and the advantages and disadvantages
would be to much for this article – if you are interested in
working on this with us, please join the OpenOffice.org
Security Project. Let's discuss the ideas on the Security
Project's mailing list, where you should subscribe
in advance, because replies normally only make it to the list.
Issue: It is worth mentioning that the META-INF/manifest.xml
and META-INF/documentsignatures.xml themselves are not signed
Update: We changed the ODF 1.2 spec (that is the version where
digital signatures are covered for the first time). The definition
for document signatures now states that all streams in the ODF
package, including manifest.xml, must be covered by the document
signatures. The only exception is that the signature stream itself
might be excluded.
In OOo 3.2, the manifest.xml is part of the document signature
Issue: Attacker can add non declared file (in particular one or
more malicious macros)
Update: As I already said in my initial comments, it doesn't
change much for security whether or not the file is declared in
manifest.xml, because manifest.xml could also be updated very easily.
But because it's good practice to make sure that all files are
declared in manifest.xml, OOo 3.2 will make this check for ODF 1.2
documents. The ODF 1.2 specification will also state more clearly
that all files need to be registered in manifest.xml.
Because older versions of OOo already registered all files in
manifest.xml, it might be worth discussing if this check could/should
also be done for older documents.
Issue: Let us consider then the case which consists in
replacing an encrypted macro with a plaintext (malicious) macro.
Update: As already explained in the first issue above, OOo won't
except any not encrypted streams in encrypted documents anymore,
independent from the ODF version used in the document.
Further improvements in OOo 3.2 and/or the ODF 1.2
ODF 1.2 now allows for using different encryption algorithms, and
all details about the algorithms used need to be documented in the
manifest.xml (which is the reason that the manifest.xml itself can't
be encrypted). These ODF enhancements have been submitted to the
OASIS ODF TC, and OOo 3.2 already implements them. Please note that
this only means OOo would put all needed information into
manifest.xml. It doesn't mean that OOo would have new built-in
encryption algorithms yet.
For other things in the loop, see the Security Project's Wiki pages.
That's great - but I can't find any download for OpenOffice.org 3.2
OOo 3.2 is not final now – expect the final version to be
available end of November.
And please make sure to only download from trusted sources, like
reason is explained