Quick answer: no.

Some news state that the latest MS Word exploit would also affect OpenOffice.org 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...

As promised, I will now give some comments on different things stated in the article "In-depth analysis of the viral threats with OpenOffice.org 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.

MULTIPLE PROGRAMMING LANGUAGES

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

ZIP AND XML

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.

NO CONSISTENCY CHECKS FOR MACROS

It is possible to insert new macros or libraries into a document, OpenOffice.org 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...

TRUSTED SOURCES

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.

INFECTION OF PASSWORD PROTECTED DOCUMENTS

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.

MANIPULATION OF OOo MENUS AND CONFIGURATION

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 VIRAL EFFECT

The article describes a lot of things that can be done in OpenOffice.org 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.

CONCLUSION

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

You might have read some news articles stating OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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.

You may have read that French article on ZDNet:
http://www.zdnet.fr/actualites/informatique/0,39040745,39362096,00.htm

Something like a translation of this can be found here:
http://arstechnica.com/news.ars/post/20060718-7288.html

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

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.

You may have seen some news about an other virus for StarOffice and OpenOffice.org.
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”

StarOffice and OpenOffice.org 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 OpenOffice.org 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...