Security Enhancements

Based on the article "In-depth analysis of the viral threats with OpenOffice.org documents", published in "Journal in Computer Virology", I had some discussions on how OOo security can be further improved.

My comments on the article can be found here:

http://blogs.sun.com/malte/entry/my_comments_on_on_the

We have fixed the bugs around password protected documents, now we should have a look at the other things.

I don't agree with some of the conclusions in the article, because most of them rely on a "primo infection", which means someone executes unsafe macros or binaries. After that the whole system can already be compromised, nothing special to OOo.

But I agree that it's easier to get code into OOo macros, than into some binaries.

There where also discussions on document integrity checking.

I describe both things in more detail below.

My personal opinion on these both topics is:

We should work on "Become more robust against viral threats", but not on the "Basic integrity checking for not signed documents", because this only let some people feel more secure, but they aren't.

I would be happy about your comments on this, so I start the thread "OOo Security Enhancements?" on dev@openoffice.org

Become more robust against viral threats

We can't hinder people from executing unsafe stuff, but at least we can make it harder for that stuff to get deeper into OOo.

Macro location, trusted sources

OOo shouldn't have automatically trusted macro locations.

OOo only checks for macros in documents, but trusts any macro that is in the “application basic”, delivered with OOo.

The reason for this is that OOo sees them as application code, like any shared library. Malicious code that is executed (with permission from the user) is able to manipulate macros as well as any other shared library (primo infection). But it's much easier to put some “virus auto start” code into macros, than in some binary shared library.

A solution could be to warn/hinder macro execution from any location, not only from documents. No path would be implicitly trusted, the default should be to execute only signed macros.

Signing all macros is difficult in an open source project, because everybody can build OpenOffice.org installation sets, but of course can't have “the” certificate for singing the macros. So administrators need some tooling to sign all macros with their own certificate and to configure that certificate as trusted. Alternatively, if signing the macros can't be done for some reason, the administrator could also put all macros in some special folder and configure that folder to be trusted.

Additionally, the administrator can configure OOo in a way that users can't add trusted locations or trusted authors. For Sun provided OOo builds it might be possible in the future that we sign all basic libraries and other shared libraries, must be clarified. An interim solution could also be to warn before any macros execution and to allow administrators and users to configure the location from installed macros as a trusted source, but don't make that a default trusted source anymore.

Basic integrity checking for not signed documents

Most people don't sign documents, but it would be nice to have some confidence that the document was not manipulated.

Integrity checks for documents

There are already integrity checks with the zip file format which is used for ODF files, but this doesn't help if some user or some malicious code manipulates document content or macros, or adds /removes something to/from the zip archive.

A solution would be to have hash values for all content of the document (zip archive). But this would make manipulations only a little bit more difficult, because the calculation of the hash values would be publicly specified (on OOo or in ODF), and even the source code for this would be publicly available.

The hash value approach is only safe when the overall hash value would be encrypted, but then we already have digital signatures and people need a certificate containing some private key. Adding this feature without encryption only raises the barrier for document manipulation a little bit and people might (wrongly) feel a little bit more confident.

An other problem is that OOo in default configuration wouldn't warn if the hash value doesn't exist, because this is the case for all existing documents, and probably still for future documents created with other applications or by some automatic document creation tools. Comments

In case people think this feature is useful: Hash creation algorithms should be the same we already use for digital signatures If done each time when saving the document, calculation must be fast, so probably no canonization of XML documents, like currently done for digital signatures

I understand the benefits of canonization, but is it really useful for XML content stored in ODF files? A normal office installation would only warn if a document contains hash values which don't match the current content, but not if no hash values are included

Administrators or users could configure OOo to also warn if no hash values exist.