By user13342178 on Feb 12, 2010
Eventually, Openoffice.org 3.2 is available for download.
Eventually, Openoffice.org 3.2 is available for download.
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.
As promised in a comment in my "Comments on the Black Hat 2009 OOo Security Briefing", I have created the OpenOffice.org Security Project.
I already did this some weeks ago, but it took me some time to transfer all the content of my currently existing documents into the Security project's Wiki pages. (This was also a good opportunity to consolidate and clean up some stuff.)
There are different pages for topics like digital signatures and encryption. On the first page you can find a list of all the different items, the ones we are working on now, as well as items that might be addressed some time later in the future.
Currently it's all about digital signatures, encryption and document integrity. I hope I will find some time to also work on stuff for avoiding security vulnerabilities, which includes using certain compiler features as well as guidelines for developers.
Every kind of help is welcome :)
Quite frequently, people ask about the document encryption used in OpenOffice.org for ODF documents. Which algorithms are used? Is it really secure?
If you try some internet search, it's difficult to find the really useful information.
To make it easier for all, including me when I again have to answer such questions, I decided to write down some information here.
ODF documents are Zip archives, and the encryption is applied to all ODF relevant streams, and not to the zip archive itself.
The encryption is described in the ODF 1.1 specification, chapter 17.3:
17.3 Encryption The encryption process takes place in the following multiple stages:
A 20-byte SHA1 digest of the user entered password is created and passed to the package component.
The package component initializes a random number generator with the current time.
The random number generator is used to generate a random 8-byte initialization vector and 16-byte salt for each file.
This salt is used together with the 20-byte SHA1 digest of the password to derive a unique 128-bit key for each file. The algorithm used to derive the key is PBKDF2 using HMAC-SHA-1 (see [RFC2898]) with an iteration count of 1024.
The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher-feedback (CFB) mode.
Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as 'STORED' rather than 'DEFLATED'. As entries which are 'STORED' must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.
So the ODF encryption can be considered to be quite strong.
If you search for ODF encryption, very likely you will stumble over many password recovery tools. But none of these tools found any weaknesses in ODF encryption. All these tools can only provide brute force attacks for ODF documents.
I found this on the web site from Intelore, one of the major password recovery tools providers:
"As a true open source product with UNIX roots, OpenOffice.org supports strong document protection for ultimate security. All OpenOffice documents can be saved with a password, enabling strong password security. OpenOffice.org uses industry standard encryption methods that are extremely hard to break."
If you have other opinions about ODF encryption quality, please let me know...
Some people contacted the OpenOffice.org security team because Kaspersky AV 2009 is reporting OOo 3.x as vulnerable (SA30599).
The security issue was already fixed in OpenOffice.org version 2.41, but KAV 2009 is reporting OOo versions starting with 3.0 as vulnerable again.
It seems that this is just a wrongly done version check. Kaspersky just confirmed to me that this would be an issue in KAV and they would work on that now.
OpenOffice.org 3.x is not affected by this security issue, so you don't have to be worried a can simply ignore the KAV warning...
Many people are discussing Evilgrade today - a toolkit for exploiting products which perform online updates in an insecure fashion.
The idea of the attack is well described on page 9+10 in this PDF document:
Step 4 is the real issue here.
All security aware people know that they NEVER should install any software when they don't know the origin, and without verifying the integrity of the package. This can (and should!) be done by verifying hash sums with values you get from the project's download page. Signing the installation packages would make this step a little bit easier and nicer, but we don't have that right now.
So when people should do that, applications of course also MUST do that - unfortunately many, including OOo, don't do it...
I hope we will have signed packages for OOo soon: While people can work around the issue with verifying MD5, OOo shouldn't contact some server for getting MD5 values, because the server could be compromised. ( I must admit that this can also happen with the user visiting a fake server which looks identical to the original server... )
Signed update packages seems to be the only viable solution to me. Using HTTPS for contacting the update server would also be a good thing. But that alone wouldn't help, since, even if this is quite unlikely, the faked server could also have some valid certificate.
As long as we don't have signed packages, it might be reasonable to use the update check in OOo only to check for updates, and maybe also for downloading them, but not to use the install feature without checking the MD5 sums manually.
MD5 sums for OOo releases can be found here: http://download.openoffice.org/md5sums.html
This was the technical stuff, so you see the problem is real.
The open question is: How likely is it that someone really will be able to control your system's DNS resolution?
In the inranet of a company it's very likely, but only the IT department should be able to do that (in theory).
For people at home I don't think that the risk is sooo big, but maybe I underestimate that. For home users, it's more likely that they download and run some Trojan horse which does the DNS resolution manipulation locally by modifying the hosts file or running a local DNS server. But then, it's not the next update from some software you have to worry about - you system is already compromised since you did allow some malicious software to run on your system...
The latest releases of StarOffice and OpenOffice.org contain 2 security fixes.
102967 reminds me that we should have a closer look on what 3rd party libraries we ship with the next major versions.
There are 3 reasons for shipping these libraries with SO/OOo, instead of making them a system requirement:
1) It's convenient for the user. Just download and install the productivity suite, don't care about additional downloads and installations.
2) Modified versions. In some cases SO/OOo ship
modified versions of 3rd party libraries, because we made some bug
fixes which are not available in the official versions from that
library right now.
3) No problems with ABI compatibility. Sometimes 3rd party libraries
change in a way that they become incompatible with current versions of
SO/OOo. Sometimes even in a way that the users doesn't recognize it
immediately (application still starts), but some things behave
differently (and wrong).
This happens for example when introducing new enum values in the middle of existing values. An example for this can be found in the FreeType library, which was responsible for one of the security vulnerabilities.
But in general, there should only be one copy of each library on a system, if possible. Programs shouldn't install "private copies".
Item #5 is exactly what we are talking about here...
...at least until you kick it!
There are currently a lot of news about SB/BadBunny-A.
Same story again like with Stardust and Starbugs, with the only difference that this one has some replication code.
Sohpos has just confirmed to me that SB/BadBunny-A does not bypass StarOffice/OpenOffice.org security checks, and that the user is asked if he wants to enable macros for that document when loading it.
So nothing bad can happen to you as long as you don't allow the macros to run.
I really can only repeat it again (and again and again):
OpenOffice.org has a macro language with access to local resources.
Of course this macro language can be used for performing any kind of tasks, that's the intention of it!
Users shouldn't run macros from unknown sources, same like they shouldn't run any programs or other scripts from unknown sources.