Wednesday September 16, 2009

Security and Privacy Feature Improvements in upcoming OpenOffice.org 3.2

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 been necessary

Issue: Encrypted documents - Macros can be added, replaced or removed

Update: In OOo 3.2, you can't anymore add unencrypted macro streams, or replaces existing streams with different (unencrypted) versions.

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 manifest.xml.

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 other applications.

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 encrypted.

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 now.

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 specification

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 http://OpenOffice.org. The reason is explained here.

Posted by Malte Timmermann ( Sep 16 2009, 01:20:10 PM CEST ) Permalink Comments [0]