Comments on the Black Hat 2009 OOo Security Briefing

Here are my comments on the white paper: OpenOffice v3.x Security Design Weaknesses, Eric Filiol and Jean-Paul Fizaine.

Statements (not quotes) from the article are marked with an italic font. For the original text please refer to the publicly available paper.

Chapter 1 - Introduction

      Some reference to issues described in “In-depth analysis of the viral threats with documents”

The listed GUI manipulations and macros in user space are not in the focus of this new article, so I just want to point to to my comments on that article in my blog.

      Unencrypted, plain documents don't have integrity control, files can be added, including executable (macro) code

Well, ODF is an open standard, so any kind of integrity check would also be well documented. Other ODF application must be able to implement them, so also malicious software knows how the checks look like. And: (proprietary) binary file formats are no more secure - they just make it more difficult (security by obscurity).

In the end, it doesn't matter: If someone adds a macro, OOo will warn, and ask if the user really wants to execute it (which he shouldn't do with documents he can't trust). If the extra content is some executable, it doesn't matter for OOo, since it will be ignored.

      Encrypted documents: Macros can be added, replaced or removed

In OOo 3.0, it's no longer possible to add or replace macros in encrypted documents. When a document is encrypted, all content streams must be encrypted, all with the same key.

Unfortunately OOo only shows a warning for not encrypted streams for ODF 1.2 documents. For compatibility/legacy reasons it's not shown for older documents. We already work on changing this for OOo 3.2, since we recognized that security should have had a higher priority over compatibility here.

[UPDATE: I was mistaken that we actually would show this warning. It's still possible to replace encrypted macros with plain text macros.]

Macros can still be removed in encrypted documents. This can't do any harm, but I agree that this might look a little bit strange for the user, since he believes this shouldn't be possible in an encrypted document.

In the team that is working on OOo 3.2 security improvements, we discussed possible solutions here. I understand that Mr. Filiol is in favor of encrypting the manifest.xml, but this can't be done, because the used encryption/hash algorithms are described there, and the ODF application need to be able to read that. (You should also recognize that ODF 1.2 will allow for using different encryption algorithms, because different countries or companies might have different accepted/allowed/approved algorithms).

Our current idea is to create a hash of the manifest.xml in a separate stream, which is encrypted with the same key like the rest of the document. OOo would then warn when the hash is broken or doesn't exist. This need some more discussion on how to explain the warning to the user, because OOo would warn for all older (encrypted) documents, and documents written with other ODF applications. The user probably will need an option to disable this warning for old documents.

Additionally, we plan to warn when some stream in the archive is not listed in the manifest.xml. The ODF specification already states that only content listed in the manifest.xml is relevant for the ODF document, so this should be fine (in opposite to the encrypted hash value of manifest.xml, which probably needs to be specified there).

      It's possible to remove the digital signature

Fine for me – can be done via OOo GUI as well, and I don't see the issue here.

(In OOo 3.2, it shouldn't be possible anymore with encrypted documents)

Chapter 2 – ODF Format and Security Features

     ZIP and ODF Format and Manipulation Tools

There are many hints on how to prove that ODF files are using zip containers – nobody ever said it would be different. I especially like the hint to the project: “goal is to provide a set of tools to directly and transparently handle and manipulate the OpenDocument format”.

In the context of this paper it sounds like this would become a tool for doing evil things – manipulating ODF documents. Actually, the whole purpose of an open standard is that different kind of tools can make use of it. So it's worth mentioning that the project actually was started from people in our team here in Hamburg. To make ODF adoption easier for other projects.

     Macro location – simple text manipulation of these files would allow to dramatically change the security status of the document

Sure: The intention of macros is that macro authors can do powerful things. Good things as well as evil things. And it doesn't matter which tool I use to create them.

People never should run macros if they are not sure that they can trust them. Full stop.

     Document encryption: It is very surprising to notice that the manifest.xml file is not encrypted

Well, I don't find this surprising, because, as I wrote earlier in this article, it contains necessary information for the ODF application about how to handle the encryption.

And as I also stated there, that we think about introducing an encrypted hash value for the manifest.xml, so it can't be manipulated anymore. The other information contained in manifest.xml is not worth hiding, because that information (mainly the stream names) is also contained in the Zip header itself.

     Digital Signatures of documents

     The information with respect to the signature are located in an additional file which is not the manifest.xml

Actually the signature stream is listed in the manifest.xml. Or was this statement about the signature not being stored in the manifest.xml directly?

     It is worth mentioning that the META-INF/manifest.xml and META-INF/- documentsignatures.xml themselves are not signed

Signing the manifest.xml is on our list for OOo 3.2. Please note that this will introduce the limitation that macro signatures can't be introduced after the document was signed, because this would need manipulation of the (then) signed manifest.xml.

I am not sure about the part with regard to signing the signature file itself. Signing the full file wouldn't be possible, because additional signatures would be stored in the same file, breaking the first signature. Needs more thinking/discussions.

     The digital signature relies on the XML-DSIG norm. However, it is itself not standardized in the OpenDocument format release 1.2 (at the present time no more information is available and the only reference is the version 1.1) yet

Please note the the specification for digital signatures has been integrated into OpenDocument-v1.2-draft6.odt (September 2007). The most current version of the ODF 1.2 specification is the Committee Draft 01-rev06.

     All the aspects related to signature (see page 31 in the paper) could be interesting for any malware which would operate directly in memory and could thus manipulate the signature during its production

Well, if you already have suspicious code running in memory, your system is already compromised and you can't rely on anything in your system anymore. You can read about my opinion about the primo infection issue here.

     Digital signatures combined with encryption: The signature file itself it not encrypted

I recently discussed this with different people. There are advantages and disadvantages in encrypting this file. It depends on your use case. In the end, this can become a privacy issue, but from my point of view, not a security or integrity issue.

     Signature and macros: The document signatures includes all streams, while the macro signature doesn't include the document streams. The document is not protected, being a major design weakness

I strongly disagree, since this works exactly as designed! Companies tend to do a lot of complex things with macros. Very often, these macros reside in templates. People use the templates and fill in some data into the document. If the macro signatures would include the document content, macro signatures would become invalid in the moment the user enters some data. With the current approach, the macro signatures will stay valid in this case. You should also notice that macro signatures have a different meaning than document signatures. They explicitly only sign the macros, not the document, and the document will not show up as a signed document. The macro signatures make sure that macros are not altered, and can be used for macro trust decisions.

     With document signatures, the whole document content is signed, including existing macros. This is a significant evolution since in OpenOffice 2.x, macros themselves were not signed. As a consequence, attacks identified earlier are no longer working, at least directly

Right. It was a wrong decision to only sign the document content with the document signature. Now the macro streams (and all other streams in the zip archive except in META-INF folder) are part of the signature. Please note that this is only for integrity checks – the macros signed with a document signature are not handled as signed macros.

Chapter 3 – Viral Attacks Through Plain OpenOffice Documents

     Simple archive manipulations (using zip/unzip utility and a simple text editor) enable to perform a lot of attacks. If we intend to modify the document payload itself (the document visible text), the principle consists in modifying the information contained within the suitable tags

Well....yes? I really wonder why people should be confused about this.

The ODF standard is defined as an open standard – not bound to certain applications. This means any application is eligible to implement ODF. Most users will use authoring tools like for creating ODF documents. But it's totally OK to use scripts which do automatic ODF/XML processing, or even using stone old VI, where the ODF logic needs to be in the authors head, because VI can only help in plain text file manipulation.

So the scenario described above is absolutely valid and welcome.

     Since no integrity check is performed, the modification remains unnoticed by the user

All kind of integrity checks would rely on hashes. Since the calculation of the hashes would be well documented in the ODF specification, and algorithms would be implemented in many open source projects, it wouldn't make it much harder for malicious code to do not recognized document manipulations. Hashes only help when you can encrypt them – this is exactly what digital signatures are good for.

     Attacker can add non declared file (in particular one or more malicious macros)

With OOo 3.2, the files will need to be declared in the manifest.xml, but that doesn't change much. For macros this is not really an issue, since they are not signed then, and shouldn't be trusted/executed. OOo will show a warning when loading the document.

Interesting is the part “It is possible to insert stolen data into an file”. (Side note: Why do people call them OOo files so often?! Please recognize that they are ODF files, and there are many ODF capable applications out there).

It's true that you could put any (stolen) content into the document's zip container, but you also can do it by attaching the data to PDF documents, where nobody would expect anything like this when forwarding the file to other people. And you probably can do the same thing with many many other file formats.

The issue here is – again, not the file format or the application, but the circumstance that you already have malicious code running on your system! This code can do anything with the current user's access rights, and there are many more interesting/efficient attacks than controlling an office application.

For the part “attackers can do macro substitution (replace macros with other malicious macros)”:

As I already said – macros which are not signed shouldn't be trusted/executed.

     Any XML compliant modification will remain undetected...

I guess this is already answered...

Chapter 4 – Viral Attacks Through Encrypted OpenOffice Documents

I must admit that I don't understand what chapter 4.1 is trying to demonstrate. The text doesn't mention what kind of document/macro manipulations has been done in the “successful case”. The differences they list (directory names in the zip header) don't mean anything to ODF and the signatures. I can only assume that they used some old documents in their tests. As I stated earlier, some checks are currently only done for ODF 1.2 documents (for compatibility reasons), and starting with OOo 3.2 we plan to do the same tests and warnings also for older documents.

     Let us consider then the case which consists in replacing an encrypted macro with a plaintext (malicious) macro.

This attack doesn't work anymore with OOo 3.0 and ODF 1.2 documents. Again – same checks for older documents to be introduced in OOo 3.2. I am really sorry we didn't do it from the beginning, “just” for document compatibility reasons.

Chapter 5 – Viral Attacks Through Digitally Signed OpenOffice Documents

     Since critical files are not encrypted and especially there is no external secure management of digital signature keys and certificate (use of PKI), it is dramatically easy to forge fake X509 certificate and play man-in-the-middle attacks.

First, I would like to clarify that OOo actually makes use of PKI.

On Windows, the Microsoft Cryptography API is used, and the certificate management and tools are the same like for all other Windows applications. On other platforms, OOo relies on NSS, which means that the certificates are managed via Mozilla Thunderbird, Firefox or Mozilla/SeaMonkey.

In the paper we see an example that someone could collect personal data of “Alice” somehow, and create a self signed certificate using most of the data, to make it look “genuine”. Bob then receives a document which seems to be signed by Alice, and Bob doesn't understand PKI and lets himself being fooled by simply reading the Name “Alice”. He is not checking the public key...

I agree that there are probably many people out there who don't know much about public key certificates and PKI. They don't understand that self signed certificates are worth almost nothing, and that they would need to check the public key somehow.

But actually, OOo 3.0 tells the user when a certificate can't be validated, which is always the case with self signed certificates. It seems that the screen shots in the paper have been done with an old version of OOo. OOo 3.x versions would show an exclamation mark in the signature sign. In the status bar as well as in the certificate dialogs.

Screen shots to show how it looks like in OOo 3.x:

- using a self signed certificate, document window
- using a self signed certificate, signatures dialog
- using a self signed certificate, certificate viewer, general page
- using a self signed certificate, certificate viewer, certification path

Please note that the document is not marked as “(Signed)” in the document window caption, and also note the exclamation mark in all symbols. All dialogs tell the user that the certificate could not be validated. So people should be aware that something could be very wrong.

Instead, they should only trust in certificates signed by some certificate authorities, with corresponding root and intermediate certificates existing in their system:

- using a good certificate, document window
- using a good certificate, signatures dialog
- using a good certificate, certificate viewer, general page
- using a good certificate, certificate viewer, certification path

Looks much more trustworthy to the user, doesn't it?

Chapter 6 – Conclusion: Enhancing OpenOffice Security

My conclusion is that OOo/ODF security doesn't look that bad like stated in the paper.

And with OOo 3.2 there should be some more improvements, as mentioned in different places in this article. Please note that I can't make promises about what things will really make it into OOo 3.2. We are working on it...

The idea in the paper about a special OOo version (“Trusted OOo”) is interesting, but would mean to create an isle. That special version would warn every time you load a document which was created/modified with vanilla OOo or any other ODF application. The extra information in the documents would be lost once edited with some other application.

With regard to allowing administrators to configure security options: This is already possible. Simply change the configuration in the office installation fitting your needs, and mark the configuration items as final. Then the user can't change or overwrite them in the user configuration via UI or direct XML manipulation. And of course you need to make sure that normal users can't write to the location where OOo is installed.

I think I don't have to comment on “closing (security related) parts of OOo”. Beside the fact that it's not an option, would proprietary software make attacks only more difficult, but not impossible.

Comments welcome...


Malte, thank you very much for clarifying point by point.
I known about this because some people from Microsoft was using this document for spreading FUD about OpenOffice,
You can check, if you speak spanish, this two entries from Microsoft Iberica's Director of technology:

I wrote three articles in spanish about this in our site:

Thank you and your team for the hard work for making the best alternative for MS Office.

Posted by sechole on April 30, 2009 at 07:57 PM CEST #

Link for original white paper not working for me.
Can you give me another link.

Posted by r4zoli on May 01, 2009 at 05:43 AM CEST #

Hi sechole,

thanks for the comment - I will ask some Spanish speaking colleague to look at the articles with me :)

Posted by Malte on May 01, 2009 at 06:33 AM CEST #

Hi r4zoli,

I just tested the link and it works fine for me. I can't provide an other link, sorry.

Posted by Malte on May 01, 2009 at 06:36 AM CEST #

I tried in FF 3.0.10 on winXP, and it not show and download damaged. With Chrome no problem with downloading.

Posted by r4zoli on May 01, 2009 at 08:41 AM CEST #

Hi Malte,
I translated your blog post into Hungarian:

Posted by r4zoli on May 03, 2009 at 08:30 AM CEST #

Thanks r4zoli :)

Maybe I should have written a smaller article, to make translations easier ;)

Posted by Malte on May 04, 2009 at 02:20 AM CEST #

We agree that they musn't be any security by obscuring. It is true, that if it exist a function that perform the control of integrity is documented in the standard, it would be known by every one. And it should be like that.
The experience shows, specially in cryptography, that it is possible to make secure system, even if the algorithm is known by every one. And that point should be the based of the security in open source software.

We are not fully conviced by a second encrypted stream containing a hash of the manifest.xml file. It could be a solution, that should be must be discussed and then be validated. The most simple and the more secure solution is to fully encrypt the document. Moreover all warning to the user would be more simple to managed.

It is not because the system is already compromised that OOo shouldn't be protected and make easier any kind of evil things. What we musn't forget, is attackers want's to perform succefulness attack. All the glorious attacks are not anymore the goal. Attackers are looking at the easiest way of getting datas and informations to make some profit with. That's the point.

We had perfom all the test with the distribution available on OOo's official site since January. And all the tests were check at most twice. When the paper was public only OOo 3.0.x was available.

In the case in OOo, the suite is used by huge kind of user, from any one to states administrations and institutions. In the last class of users like governement or militairy institution, they need some special security issues without the possibility to use the trustfulness of users to performs an attack.

What we pointed, is that all the choise that were taken are first on usefullness and secondly on security. Because of that, it is easy to perform attacks that use the user trustfulness. This shouln't be possible, or should be the more difficult as possible to perform. Moreover it is not safe enought to exchange hight confidential data or information. That's main the problem.

If OOo is used in sensitive environnement, it must be the more secure as possible. So effort must be continued in order to make OOo more and more secured. And this security must be stressed as deep as possible, in order to correct the weaknesses.

Eric Filiol & Jean-Paul Fizaine

Posted by Eric Filiol & Jean-Paul Fizaine on May 11, 2009 at 06:01 PM CEST #

"The most simple and the more secure solution is to fully encrypt the document"
1st-Sorry, but if you close the document as you proposed, How can other application can read it?
Remember ODF is Open.
2nd-I check the paper, specially on page 52 onwards. Where its demostrate the wekeness of digital signature.
I understand that you are trying to demostrate that self-signed certificates are susceptible to man-in the middle attack. And you are correct!.
It could be possible to fake self signed certificate and you could fool a user, but not depends on OpenOffice thats depends on the user who accept the document.
Try to do the same with a Verisign, Thwate o Entrust certificate.
By the way I cannot reproduce what you are saying Maybe my OpenOffice is different than yours.
Oh! and please check on page 58, the openssl syntax is wrong.

Posted by sechole on May 11, 2009 at 06:56 PM CEST #

Hello Eric Filiol & Jean-Paul Fizaine,

thank you for your comments here :)

The intention with the encrypted stream containing a hash of the manifest.xml file is only for hindering manipulations, not for privacy. For this use case, it should be sufficient.
For privacy, there shouldn't be much „valuable“ information in the manifest.xml, which is not also in the zip headers. So for solving this, it even wouldn't be enough to also encrypt manifest.xml, like suggested in your paper, but you would need the encrypt the zip in a way that no archive information can be retrieved w/o the decryption key.

This approach indeed would have some advantages (and probably also disadvantages), but would need to be done in a way that it's specified in ODF, and that it still would be possible to get information about which algorithm is to be used for decrypting the archive.

Wrt „not safe enough to exchange high confidential data or information“: ODF uses strong encryption. So non of the confidential data would be revealed, except signature information.

Of course we try to improve security continuously. I hope all the things I mentioned in my article will make it into OOo 3.2, and we also discuss additional things that could be done...

Posted by Malte on May 12, 2009 at 10:08 AM CEST #

Hello every body.

Sechole, you are right in the case of Verisign and co certificat. If Alice and Bob are using such certificat a MID attack can't be realized. So that's mean that both Alice and Bob takes attention about cryptography. As a conclusion a PKI must be used, if signature is needed.
About the MID attack that is we've describe in the article, we made a full demonstration at black hat and we used exactelly the same openssl syntax. Everything was detailled in the conference. We used OOo 3.0.x at the demonstration. The core of the attack is to forge a new fake certificat. The syntaxe may change between the installation.

Malte, you're welcome.
You mustn't forget that security in cryptosystem is based on Kerchoffs' assumption (1883). The attacker know exactly how the algorithm works. The security is only the strongfulness of the key. So Given the algorithm, and all the maximum of information except the key, the attacker can't decipher the encrypted text or find the correct key.
So that why we say, the algorithm must be documented and open, so it can be implemented in other product whitout closing anything.
It's important for OOo, that we work together to improve the security. And we are available to help you in your decision and to give our point of view. We are waiting for you to propose a working process.

Posted by Eric Filiol & Jean-Paul Fizaine on May 16, 2009 at 10:30 AM CEST #

Sorry but the openssl sintax in your document is wrong:
First part is correct:
openssl req -newkey rsa:1024 -x509 -keyout CharlieKeys.pem -out CharlieCert.cert

Second part when you convert X509 to PKCS#12 format is wrong:
openssl pkcs12 -export -in CharlieCertX509.pem -inkey CharlieKeys.pem -out CharlieCertX509.p12

You obtain an error because CharlieCertX509.pem does not exist.
I don't known how you made a demonstration with that sentence.

Posted by sechole on May 16, 2009 at 06:58 PM CEST #

Hi Eric Filiol & Jean-Paul Fizaine,

my plan is to create a Security (incubator) project on, with the goal to work on security related things longterm.

I hope you both will join that project then :)

(@sechole: the syntax in the paper is correct, but the name from the cert file is wrong, replace CharlieCertX509.pem with CharlieCert.pem)

Posted by Malte on May 18, 2009 at 04:43 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

Malte Timmermann


« February 2017