Monday Apr 18, 2011

AES encryption for

The ODF 1.2 specification allows for stronger encryption algorithms, and Blowfish is declared as the legacy encryption algorithm.

The new version of the standard allows the encryption algorithms listed in §5.2 of xmlenc-core.

Many people wanted to see using AES encryption instead of Blowfish - and exactly this is what we have implemented for 3.4.

AES-256 encryption will be used for ODF 1.2 documents, but when you configure OOo to use ODF 1.1 or older, then of course Blowfish will be used.

In case you want to use the old encryption and hashing algorithms for ODF 1.2 documents you can configure OOo to do so. As this shouldn't be the case for most people, there is no UI for this, but the configuration files need to be changed directly. See the feature mail for more details.

Wednesday Feb 02, 2011

FOSDEM 2011, minor update

Just a minor update to my previous blog post: One presenter had to cancel his trip on short notice, so a slot in the accessibility devroom needed to be filled.

I initially didn't want to give a presentation, but to fill the gap, I will now step in and give a presentation related to, Accessibility and IA2 on Sunday, 10am.

The schedule on the web site should be updated soon.

Monday Jan 31, 2011

Going to FOSDEM 2011

This year I will be at the FOSDEM in Brussels, February 5-6.

Working on one of the largest open source projects,, for more than 10 years now (and of course many more years before the source code of StarDivision's/Sun's StarOffice went public), this is actually my first FOSDEM! Unbelievable, isn't it?

I wont give a presentation there, but I will participate in the Accessibility Dev Room on Sunday.

I guess this will be a great opportunity to meet people working on accessibility related stuff :)

Friday Mar 19, 2010

The Sun ODF Plugin for Microsoft Office and the Excel issue after uninstalling or upgrading the Plugin

Many people complain about an issue they have with Excel after uninstalling or upgrading the Sun ODF Plugin for Microsoft Office: When starting Excel, Excel complains that the Add-In odfaddin.xla can't be found: 'C:\\Program Files\\Sun\\Sun ODF Plugin for Microsoft Office <old version>\\converter\\odfaddin.xla' could not be found. (...)

I would like to point out that this is not an issue from the ODF Plugin installer, but in Excel itself:

The ODF Plugin installer writes some HKEY_LOCAL_MACHINE entries into the registry to activate the Plugin, and these entries are removed when uninstalling the Plugin, or point to the correct version when doing an upgrade installation. But for some reason, Excel will put a reference to the Add-In file odfaddin.xla into the user's configuration (HKEY_CURRENT_USER) when starting Excel after the ODF Plugin installation. This entry - of course - won't be removed from the installer when uninstalling the ODF Plugin.

So to get rid of the annoying error message, you need to remove that reference yourself:

In Office 2007, use Microsoft Office Button => Excel Options => Add-Ins => Manage Excel Add-ins (Go...) => uncheck "Odfaddin". In older versions, use Tools => Add-Ins => uncheck "Odfaddin"

If it doesn't work (which seems to happen at least in Office 2007 after upgrading the ODF Plugin), remove the reference to the old Add-In in the registry directly: HKEY_CURRENT_USER\\Microsoft\\Office\\<version>\\Excel\\Options => "OPEN"="\\"C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office <old version>\\\\converter\\\\odfaddin.xla\\""

In more detail - this happens in the different phases when installing the ODF Plugin, running Excel and then uninstalling or upgrading the ODF Plugin:

Step 1: Installing the ODF Plugin:


  + [HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\CLSID\\{16A1C170-D2C8-423B-AEC6-BAD7A26F1828}\\InprocServer32]
  + @="C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.dll"

  + [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Office\\Excel\\Addins\\ODFAddIn.Connect]
  + "Description"="Load and save files in OASIS OpenDocument format"
  + "FriendlyName"="ODF Add-in"
  + "LoadBehavior"=dword:00000003 
Step 2: Starting Excel (now Excel creates the entry that leads to the problem):


  + [HKEY_CURRENT_USER\\Microsoft\\Office\\12.0\\Excel\\Options]
  + "OPEN"="\\"C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.xla\\""
Step 3a: Uninstalling the ODF Plugin (all entries written by the installer are being removed): 


  - [HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\CLSID\\{16A1C170-D2C8-423B-AEC6-BAD7A26F1828}\\InprocServer32]
  - @="C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.dll"

  - [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Office\\Excel\\Addins\\ODFAddIn.Connect]
  - "Description"="Load and save files in OASIS OpenDocument format"
  - "FriendlyName"="ODF Add-in"
  - "LoadBehavior"=dword:00000003

  still there (of course!):
  "OPEN"="\\"C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.xla\\""
Step 3b: Upgrading the ODF Plugin, instead of uninstalling:

  - @="C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.dll"
  + @="C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.2\\\\converter\\\\odfaddin.dll" 


  still there (of course!):
  "OPEN"="\\"C:\\\\Program Files\\\\Sun\\\\Sun ODF Plugin for Microsoft Office 3.1\\\\converter\\\\odfaddin.xla\\""

So if Excel has a reference to the Add-In, Excel should probably simply disable the Add-In when it doesn't exist anymore, instead of complaining over and over again. Or at least ask the user whether or not to keep the entry...

Friday Feb 12, 2010 3.2 available - a highly recommended update

Eventually, 3.2 is available for download.

This update is highly recommended, not only because of the many security fixes and security feature improvements, but also because of some noticeable performance improvements.

As always, make sure to only download from trusted sources, like The reason is explained here.

Thursday Nov 12, 2009

Odt2DAISY - create DAISY Digital Talking Books with!

Vincent Spiewak has finished his extension for converting ODF text documents to DAISY Digital Talking Books - you can find the press release here.

The extension not only creates XML content, but also can make use of different text to speech engines, so you will have fully featured talking books.

I recommend this extension for everybody who wants to create DAISY books. Binaries and source files are available on sourceforge, the license is LGPL 3.

If you never heard of DAISY before, you might want to look at the screen casts which will show you how it works.

Thank you very much for this great extension!

Wednesday Sep 16, 2009

Security and Privacy Feature Improvements in upcoming 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 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 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 The reason is explained here.

Friday Sep 11, 2009

Big Win for ODF

IBM asks all their employees  to stop using Microsoft Office, and completely switch to Lotus Symphony - IBM's office suite which is based on 1.1.

The important thing here is not that all employees should use IBM software, which you would expect anyway (eat your own dog food). The important thing is that the main goal with this is to completely switch to the OpenDocument Format (aka ODF) - the free and open standard for office documents.

I guess this might have some signaling effect for many other companies - ODF is the broadly accepted free and open standard for office documents. Most people wouldn't consider Microsoft's OOXML format as an alternative, and meanwhile almost everyone knows that it's important to migrate away from Microsoft's binary document format - to ease further document processing, to make sure that you will still be able to read you documents in many years, and to avoid further vendor lock-ins.

Right now I could only find German news articles about this, but I am sure English articles will show up later this day.

Friday Jul 10, 2009 Security Project

As promised in a comment in my "Comments on the Black Hat 2009 OOo Security Briefing", I have created the 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 :)

Wednesday Jun 03, 2009

Sun ODF Plugin 3.1 for Microsoft Office

A new version of the ODF Plugin for Microsoft Office is available.

As I wrote in the last ODF Plugin announcement, the Plugin nowadays uses the same version number like the underlying version, so this version is now based on 3.1.

Some people asked for it, so I have added the possibility to disable the update feature and the registration feature.

Since the registration will only be triggered once after installation (and you don't have to register!), and the update feature never executes automatically, disabling these features is probably only interesting/needed in enterprise deployments. See the FAQ for details.

Friday May 29, 2009

ODF / Document Encryption

Quite frequently, people ask about the document encryption used in 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:

  1. A 20-byte SHA1 digest of the user entered password is created and passed to the package component.

  2. The package component initializes a random number generator with the current time.

  3. The random number generator is used to generate a random 8-byte initialization vector and 16-byte salt for each file.

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

  5. 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, supports strong document protection for ultimate security. All OpenOffice documents can be saved with a password, enabling strong password security. uses industry standard encryption methods that are extremely hard to break."

If you have other opinions about ODF encryption quality, please let me know...

Wednesday May 27, 2009 Connector for Alfresco CMS

People using Alfesco, the Open Source Alternative for Enterprise Content Management, might want to try our brand new OOo extension "Sun Connector for Alfresco CMS".

It was just released today, feedback welcome.

Thursday May 07, 2009 3.1 released - download the genuine and FREE version now!

The final version of 3.1 is available for download now!

A lot of new features and improvements make it really worth updating to this new version.

Important: Make sure to download genuine from a trusted site!

Almost daily, the Security Team receives mails from people who downloaded from commercial sites and had to charge for that in advance, or are asked for some kind of key or serial number when they want to install.

Selling is allowed, and is fine as long as you get some extra service, like a CD, printed handbook or support. Unfortunately, some people and companies try to make easy money with, without providing any extras, and these download sites are often in the first hits when searching for OOo downloads.

If you are not sure whether or not a download site can be trusted, simply use is very easy to remember, and mirrors make sure that you don't have to care about optimal download locations yourself.

Thursday Apr 30, 2009

Using the Sun ODF Plugin for Microsoft Office with Office 2007 SP2

ODF is now nativity supported if MS Office 2007 with Service Pack 2.

Nevertheless, people asked if it would still be possible to use the Sun ODF Plugin also in Office 2007 SP2, because the ODF quality might be better.

I just gave the final version of SP2 a try, but only to verify that the Sun ODF Plugin still can be used. My intention was not to figure out how good the native ODF filters in SP2 are.

OK, I must admit that I couldn't resist to quickly figure out what would happen with tables in presentation, because I know that SP2 only implements ODF 1.0.

Tables in presentations got specified in ODF 1.2, same holds true for formulas in spreadsheets. As expected, you might want to continue using the Sun ODF Plugin if you need these features.

If you want to use the Sun ODF Plugin for ODF documents, instead of he new built-in filters:

  • Don't open documents via the Windows explorer. You must use the file picker in MS Office
  • In Word, make sure to use the filter "ODF Text Document (\*.odt;\*.ott)"
  • In Excel and PowerPoint, use the "Export ODF" menu or tool bar items

In Excel and PowerPoint, using the new built-in filters is more convenient, because you can simply use open/save, instead of the extra UI. But the fact that the filter in Excel doesn't support formulas let me think that this filter is quite unusable for most users... (Don't get fooled when testing it: Formulas written with Excel will work when loading the same ODF file in Excel, because the information about the formulas is preserved with the help of some MS Office specific XML tags, which no other ODF application will recognize)

Alternatively, now that you are interest in ODF, you might want to give a try, in case you not already did so...

Update on my Black Hat 2009 OOo Security comments

I have to correct something that I just wrote in my Black Hat 2009 OOo Security comments.

My colleague who is working on the encryption stuff just pointed me to the fact that we have fixed the bug with macros in encrypted documents sometimes not being encrypted, but that we don't show the warning  that I mentioned. Reason was (again) the compatibility thing.

I am really sorry for my false statement about this, and that the attack described in the paper (replacing encrypted macros with plain text macros) still works in OOo 3.0 and 3.1.

I will do my best that we change this in the upcoming OOo 3.2 version, and show the warning as promised...

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

Tuesday Mar 31, 2009

KAV 2009 OOo issue fixed

This issue with KAV 2009 reporting OOo 3.x as vulnerable is already fixed.

Thanks to Kaspersky for handling this so quickly - the update was available just one week after I contacted them :)

Monday Mar 23, 2009

Kaspersky AV 2009 is wrongly reporting OOo 3.x as vulnerable

Some people contacted the security team because Kaspersky AV 2009 is reporting OOo 3.x as vulnerable (SA30599).

The security issue was already fixed in 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. 3.x is not affected by this security issue, so you don't have to be worried a can simply ignore the KAV warning...

Friday Feb 13, 2009

About the update feature in the Sun ODF Plugin for Microsoft Office

One of the questions I receive quite frequently is whether or not it would be possible to disable the update feature from the Sun ODF Plugin.

Well - from my point of view, this wouldn't change much, because the update feature doesn't look for updates on it's own, nor would it download or install anything itself.

I tried to explain that in the FAQ, but it seems someone decided my explanation would be too long or too technical, and shortened the item in the FAQ.

For those who want it explained a little bit more, here is my original FAQ item:

Q: Can I disable the auto update feature?

A: No. The auto update feature just checks whether or not a newer
version is available, but it doesn't download or update anything on it's
own. Also the check is never done automatically, but the user has to
select it manually. When a newer version is available, the same download
web site will be presented to the user like when he would look up for a
new version there. Download and installation is the same procedure like
for users who don't use the Sun ODF Plugin for Microsoft Office yet, so
there are no additional other mechanisms involved which a system 
administrator might want to restrict.

Makes sense?



Friday Feb 06, 2009

Sun ODF Plugin 3.0 for Microsoft Office

Finally, a new version of the ODF Plugin for Microsoft Office is available!

It's been a while that we have released version 1.2 - but hey, why is it called 3.0? Did I miss version 2.0?

Well, the answer is very simple. I thought it would be a good idea to give it the same version number like the underlying version of

This way, people know exactly which versions of the conversion filters are used.

The conversion between ODP/PPT and between ODS/XLS is exactly the same like in the equivalent version of

The conversion between ODT/DOC is basically the same, but might differ in some case because the Word Filter API is based on RTF, so there is an additional conversion involved.

This version of the plugin supports ODF 1.2 and loading ODF template files. The conversion filters have been further improved.

Friday Dec 19, 2008

Configuration Viewer - a new and very useful extension

My colleague from the NetBeans team (who happened to be my SEED mentee), just uploaded his new extension for

It's the Configuration Viewer extension.

This useful extension lets you see all key/value pairs from your configuration - even those that are not accessible via the user interface. It distinguishes between configuration items stored in the shared configuration layer and the user's custom configuration. A little checkbox on the bottom of the dialog helps you for quickly identifying configuration items which are storade in the user's configuration layer. With the Export button you can export the currently displayed configuration items into a text file.

After installing the extension (which needs Java to run), you can find it behind a new menu item: "Tools / Configuration...".

If you think this is a useful extension, let Stan know via a comment - maybe he will then continue working on it, adding other cool stuff like editing the configuration items :)

Tuesday Nov 11, 2008

IAccessible2, or - IBM to contribute to the 3 code line!

This was one of my personal highlights in the keynotes from the 6th conference last week:

In his talk, Michael Karasick, Director of Lotus Development IBM China, has promised that IBM would eventually contribute to the OOo 3 code line. And he especially mentioned IAccessible2.

So I hope to see this happening soon, volunteering to work together with the Team from IBM on this.

Tuesday Oct 21, 2008

3000000x3 version 3 is available for 1 week now, and was already downloaded more than 3 million times!

And this is only what we can count - it doesn't include torrents and other ways of distributions.

More information and links in this blog.

Tuesday Aug 05, 2008

Evilgrade and - Online updates realy can be dangerous

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:

  1. An Application is checking some update server for updates, using some domain name
  2. The attacker has control over the DNS resolution and returns an IP from a server he controls
  3. The application downloads something which should be an update, but in reality is some back door software or other kind of Trojan horse
  4. The application executes or deploys the binaries it received

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:

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

Thursday Mar 20, 2008

Back from CSUN

Last week I was attending the CSUN conference - probably the biggest and most exciting Accessibility conference in the world.

The different presentations made it clear: Web Accessibility, ARIA and AJAX are still very hot topics.

For Windows Accessibility, IAccessible2 is still making a lot of progress. Some Screen Readers already have support for it, and I hope we will have it in soon.

I gave a small talk in an IAccessible2 session, my presentation can be found here.

Of course I have used the cool PDF export in, which allows you to create well accessible, tagged PDF. Unfortunately, creating tagged PDF is not the default, because of the increased file size. I hope we will change the default eventually. For now, use the "Export as PDF..." menu item in the file menu, which will give you a dialog where you can check the option to create tagged PDF. The tool bar item skips this dialog.

In parallel to IAccessible2 on Windows, we are also working on support for the Mac OS X Accessibility Framework!

We have shown the latest builds to some AT vendors, and it seems they are very exited about this. From what I heard, not many applications on Mac OS X have good support for this right now.

So with all our Accessibility work going on, I am very confident that 3.x will be very accessible on many different platforms, with native support for the platform specific Accessibility frameworks!




Thursday Mar 06, 2008 goes LGPL v3! will switch to LGPL v3 with the upcoming OOo 3.0 Beta.

Beside that, we will also exchange the old Joint Copyright Assignment (JCA)  with the Sun Microsystems Inc. Contributor Agreement (SCA), which has some advantages for contributors. This change is effective immediately.

More details can be found here.


Malte Timmermann


« April 2014