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.

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.

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

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

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

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

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.

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.

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:

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.