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

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.

Comments:

It might be possible to use a Trusted Computing infrastructure (e.g. the TPM support in Linux) to allow the user and/or distro to sign macros/scripts. This, in conjunction with signature checking on executables (again distro/user-set) would protect the next layer up from the application (OS->App->Scripts). TPM support under Linux is available now.

Posted by Giuseppe Verde on August 16, 2006 at 11:51 PM CEST #

TPM support is not enough. The OS must do the integrity check of the (signed) applications, otherwise the app code can already be compromised and will not care about configuration signatures.

Posted by Malte Timmermann on August 17, 2006 at 02:10 AM CEST #

Yes, that's what I said.

Posted by Giuseppe Verde on August 17, 2006 at 07:18 AM CEST #

" 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. " In which CWS has this bug been fixed?

Posted by KAMI on August 19, 2006 at 01:49 AM CEST #

Post a Comment:
Comments are closed for this entry.
About

Malte Timmermann

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today