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.

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 :)

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

Thursday Apr 30, 2009

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

Tuesday Feb 03, 2009

How useful is encryption?

Well, I consider it very useful - but I really like this one :)

xkcd comic

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

Monday Jun 18, 2007

The problem with shipping 3rd party libraries with your product

The latest releases of StarOffice and contain 2 security fixes.

Some information about this can be found in the Sun Alerts 102917 and  102967.

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

Funny. I was just searching for some public documentation about our ARC Process, because ARC also checks for private copies, when stumbling over a very recent OpenSolaris blog from a colleague.

Item #5 is exactly what we are talking about here...


Wednesday May 23, 2007

SB/BadBunny-A, a harmless little bunny... 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/ 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): 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.




Tuesday Dec 19, 2006

Does the latest MS Word exploit also affect Writer?

Quick answer: no.

Some news state that the latest MS Word exploit would also affect Writer.

This is an assumption because OOo crashes when reading the manipulated Word files.

The OpenOffice Security Team did take a closer look at this, and the result is that depending on platform and compiler, OOo tries to allocate a very big or an invalid amount of memory and simply crashes. We don't see how this could be used for arbitrary code execution.

To bad that OOo crashes, but not a security issue...

Wednesday Aug 16, 2006

My comments on on the article "In-depth analysis of the viral threats with documents"

As promised, I will now give some comments on different things stated in the article "In-depth analysis of the viral threats with documents".

This blog entry is quite long, so if you are not interested in so many technical details, you better skip it and just read this one.

The article, which is set to be published in "Journal in Computer Virology", lists a lot of different things with a lot of details.

I won't comment on all the individual items, but more on the different categories.

Statements (not quotes) from the article are marked with an italic font.


The article states that through OOo's support for multiple programming languages more sophisticated viruses can be written.

The different programming languages also enable the user to write more sophisticated solutions for For the security it doesn't make a difference. A macro (OOoBasic as well as VBA) can do almost everything with current users credentials, so using other programming languages doesn't increase the risk.


Well known formats with a bunch of existing tools make manipulations easier and the ZIP container can contain any malicious executable.

These standard formats make it really easier to inject code, but they also make it easier to detect it. The way how OOo stores the macros in the zip container makes it also very easy for people to detect and remove them automatically, for example in their mail gateway. Code injection is also possible with binary file formats, only more difficult. Integrity checks with check sums can be manipulated in both situations. Not to forget that the next default file format from Microsoft Office also consist of XML and ZIP files, same situation here.

The article also states that documents, or better the ZIP containers, are not password protected, what could prevent manipulations.

Of course they are not password protected. The good thing with OpenDocument is that it is an open standard, and that you have multiple applications for processing your documents. Automatically encrypting all documents or zip containers would mean that you can open them only with closed source software, and you very probably have to pay license fees for that software. And you probably will not be able to use that software on so many different platforms.

Another point is that compressed format allows injections of larger code, because file size will not increase so much.

Well, did you ever compare file sizes of your documents from time to time? I don't...

OpenDocument files are quite small, code injection results in small file increase. Microsoft Office files are much larger, code injections result in larger file increases. In the end the percentage increase might be similar, so you won't stumble over it. And if you care for file size changes, you care for every change, not only for big ones.


It is possible to insert new macros or libraries into a document, doesn't recognise it to warn the user.

This is a similar problem like described above. If you introduce check sums, that has to be specified in the OpenDocument format, because other OpenDocument applications would have to do it the same way. And of course the virus can then also do it...


Some locations are trusted per default, there is no security warning when macros in that locations are executed.

This is not true, there are no trusted locations per default. Fact is that security warnings are only given for macros contained in documents, not for macros that are part of the OOo installation. Someone who has access to theses locations can also manipulate everything else, see “The Viral Effect” later in this article.


In some cases the macros in a password protected document are not encrypted, so infection of password protected documents is possible.

Here the authors of the article stumbled over a real implementation bug. Of course the macros in password protected documents must be encrypted. This is normally the case, but under some certain circumstances this sometimes didn't happen. This bug has already been fixed.


The article states that it possible for a virus to manipulate menu entries or bind macros to events and keystrokes, because they are stored in XML files. It's also possible to disable security warnings or to configure some http proxy which might catch some data.

Well, if a virus is already running, or some malicious code is just doing the first preparations for a virus, that can be done. But now it's already too late for the user. This code can do the same modifications to a lot of other programs, which leads us to “The Viral Effect” below...

They suggest to use digital signatures for signing configuration files.

How can that work in an open source software? And even for closed software this is not an adequate solution. If you put your private key somewhere into the application, people will find a way to get it. And it only helps for the specific application, not for checking the integrity of your whole system. So if you are interested in that, you better take a look at "Trusted Computing".


The article describes a lot of things that can be done in to have a viral effect. One thing is that the configuration is XML, and therefor security settings and menu entries can easily be changed. Code for viral effects can be injected into multiple places, for example into documents, macros in OOo folders or on Unices into the shell scripts which are used for starting the OOo binary.

All of this is true. But as I already wrote in my previous blog entry: This only works with some initial infection of the system, and is not restricted to manipulations of OOo. If you allow the initial infection, your complete system might be compromised.


This time I talk about my conclusion, not about the one in the article :)

Almost everything in the article relies on the fact that some initial infection of the system is done. As I already wrote, from that moment on your complete system might be compromised, not only OOo. You can read about a lot of things that can be done when you already have a virus on your system, and how to use OOo for the viral effect. All these things can be done with any application.

I agree that there is room for improving OOo security, to make it a little bit harder for viruses. But you can't reach 100% security. The only way for achieving this is Trusted Computing, which is not available right now. You need special hardware, BIOS and operating systems for this.

But there are things the users already can do do minimize risks.

  • Don't work with admin/root rights, use them only when needed for performing certain tasks

  • Don't run binaries that you can't trust for some reasons

  • Don't execute macros in documents you receive, unless you can be sure it's safe

As I wrote in my previous blog article, I don't share the opinion that is less secure than Microsoft Office.

When it comes to macros, both applications have the same problem: Users blindly run macros in documents they receive. They explicitly allow macro execution, because always asks them if to execute macros contained in a document.

From the file format point of view, I think OpenDocument files with their usage of XML and ZIP are more secure than binary document files, because it's much easier to check for included binaries or for the existence of macros, and all these things can very easily be removed.

When it comes to application manipulations from some malicious binary, they are both effected in the same way like all other installed software and the operating system itself.

Is less secure than Microsoft Office?

You might have read some news articles stating being insecure, maybe even less secure than Microsoft Office.

All these articles are based on the article "In-depth analysis of the viral threats with documents", set to be published in "Journal in Computer Virology".

The article talks about conceptual problems only, not about security exploits where security checks are bypassed.

From this point of view, there can't be a big difference between and Microsoft Office. Both come with a scripting language to enable the user to write powerful and sophisticated macros. I already wrote about this here.

All scenarios described in the article have one thing in common: They rely on some initial infection ("primo infection") of the system.

There are two ways for achieving this:

  • The user starts some executable containing a virus or trojan

  • The user loads a document with malicious macros which are (automatically) executed

So how does it come to the infection?

Normally users shouldn't start any executable they receive via email or from strange web sites.
But maybe some vulnerable code from the browser or any other program does it automatically...

Users shouldn't run macros from unknown documents.
In they get a security warning when loading such documents, and must explicitly allow macro execution...

It doesn't matter how the primo infection is done, what matters here is that a primo infection is done in some way, and that this infection code can do anything with current users privileges.

The code doing that infection does not have to be limited to making modifications to OOo, for example to disable security checks or for injecting some virus code into OOo macros.
The primo infection code can also update system wide or user specific (auto) start scripts or infect popular files like the shell binaries, browser and email clients, or install a key logger.

So if you start some malicious code on your system, it's not only OOo you have to worry about...

If you are interested in some more annotations on the different things stated in the article, you can find them in a separate blog entry which I will post soon.

Monday Jul 24, 2006

French department of defense damns

You may have read that French article on ZDNet:,39040745,39362096,00.htm

Something like a translation of this can be found here:

First thing to notice is that the article is not speaking in the name of the French department of defense. There should be some clarification soon.

Last week, I and some colleagues here in Hamburg had the opportunity to speak with Mr. Filiol, who is working on the internal security study about

We talked about 3 different issues, but I can't talk about all details here.

One of the issues is simply a bug which we should fix soon. But it is not really a security issue, but more about how users trust certain kind of documents.

An other issue was about how our trust in installed macros might ease viral effects, and we talked about some interesting options here.

The last point was about integrity checks for documents, which can also give users some more security.

All together, I must say that it was really a good call, and that Mr. Filiol and his organization are really in favor of open source software. They like our short response time, which they probably won't have in some commercial products.

Tuesday Jul 04, 2006

About the just fixed File Format Vulnerability

While the Macro and the Java Applet vulnerabilities where found by some Sun security audits, the File Format Vulnerability was reported from NGS Software Ltd.

They reported it to the Security Team, and didn't publicly disclose the vulnerability before we where able to provide updates with fixes for this issue.
Thanks for that!

This was also the first security issue handled completely by the Security Team.
Security People from Sun and from different Linux distributions are member of the Security Team. After we received the report, all of them investigated into that for different and StarOffice versions.
And this was really good, because in the first step I thought the problem was already fixed in latest OOo builds.
But it wasn't - it was just hidden from a new memory manager implementation.
The buffer overflow still existed, but OOo didn't crash with the new memory manager.

Good to have this great Security Team :)

Monday Jul 03, 2006

About the latest StarOffice and security vulnerabilities

By now you might have seen Sun's and's security alerts.

I just wanted to tell you that this is not “stardust” or “starbugs”.
These two where not able to bypass any security checks.

But the appearance of 'intended' viruses for StarOffice and caused some Sun security specialists to do deeper security audits.

In the end, they found the two issues with Macros and with Java Applets.

The way how they tricked StarOffice with macros was really interesting for us...

An other thing that we have learned from stardust and starbugs:

The security holes are fixed now, but people might still execute unknown macros, because they ignore all warnings.

I hope AV vendors will implement better support for ODF files soon, so these people are better protected, at least against known malicious macros.

Monday Jun 12, 2006

Some information about "SB.Starbugs"

You may have seen some news about an other virus for StarOffice and
Symantec has reported it as SB.Starbugs.

I wasn't able to get the sample from Symantec, because such things are only given to AV vendors.

But Peter Ferrie from Symantec confirmed that "SB.Starbugs doesn't bypass OOo security checks and OOo will ask the user if to enable macros for that document. There are no exploits, no security concerns."

So SB.Starbugs does have some replication code, which might classify the macro as a virus, but OOo will not execute it without asking the user.

Again, it's just a macro, see “Some words about 'Macro Security' in office applications

Thursday Jun 08, 2006

Some words about “Macro Security” in office applications

StarOffice and have a macro engine for good reasons.

You can create very useful solutions based on an office suite, or you can easily automate some tasks.
With macros, you can do almost the same things like with a stand alone native or Java application.

Macros have full access to system resources!

If a user runs a macro, he should be aware that it's the same like running any (downloaded) program.

When loading a document, StarOffice and check if there are macros included.

The user can choose between different security levels for macro execution in "Tools / Options / Security / Macro Security":

  • Low (not recommended): Macros are executed without confirmation request.

  • Medium (default): Confirmation required when executing macros from untrusted sources.

  • High: Only signed macros from trusted sources are allowed to run.

  • Very high: Only macros from trusted file locations are allowed to run.

Trusted sources means that the macros are signed by certain people or that the documents are stored in certain locations.

To completely disable document macros, simply set security level to "Very high" and don't configure any trusted source.

My recommendation: Never run any macros if you are unsure whether it's safe.
Same like how you would treat downloaded program files, I hope...

Tuesday Jun 06, 2006

Some information about "stardust"

Currently there are a lot of news about "The first macro virus for StarOffice and".

I got the "proof of concept virus" from some antivirus company and looked a little bit deeper into that.

It's a macro in a sxw file, I can't find anything interesting there.
I asked the AV company if that is the "original", they confirmed it.
So I wonder why some news state, that it works in StarOffice 5.2, that file even can't be loaded there...


It doesn't act as a virus in any version of StarOffice or

It's even not a valid proof-of-concept!


1) It doesn't start!

When the file is loaded, the user is asked if to enable macros from this document.
Even if the user choose "yes", there is no auto-start of any macro.

2) It doesn't do anything special

When the user manually starts the macro, the only thing that happens is that an image should be loaded into a new document, and some text is written in the current document.
That's all!

3) No self reproduction

There is some sub routine called "InstallGlobalModule".
It's commented out, but even if you try to activate it, it doesn't work.


This is not a virus, even not a proof of concept. 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.


Malte Timmermann


« June 2016