2007-09-01
Abstract
Eric Filiol and Jean-Paul Fizaine report on the security weaknesses of the OpenOffice suite.
Copyright © 2007 Virus Bulletin
The prevalence of macro viruses for Microsoft’s Office suite has declined sine its peak in 2000, and recently we have seen the evolution of office software towards free, open source software in the form of the OpenOffice suite, which provides compatibility with many different operating systems. This two-part article presents an up-to-date evaluation of the security of OpenOffice (release 2.2.x), based on the results of a study undertaken during the summer of 2006. Some worrying security weaknesses have been identified, which could be used by malware to spread through innocuous-looking documents by exploiting the feelings of trust engendered by document encryption and digital signature.
This paper will discuss on a purely technical basis the pros and cons of both open and proprietary solutions as far as security is concerned. There is no such thing as a perfect solution – therein lies the complexity of computer security.
For the last two years, the OpenOffice suite has been positioned as an open and free alternative to existing commercial office software suites. Equipped with a lot of sophisticated functionality, OpenOffice represents a credible, high-quality solution. Since version 2.x.x, the software has undergone a rich evolution to provide the user with an ergonomic environment. Several development environments are available as well as dedicated tools that greatly enhance the suite’s overall functionality. But the existence of such an environment and capabilities raises questions as to the security of OpenOffice with respect to malware.
An in-depth study of the OpenOffice environment (releases 2.0.2 and 2.0.3 under Linux, Mac OSX and Windows) was conducted between June 2005 and July 2006 in the Virology and Cryptology lab at the French Army Signals Academy. The results were initially published in July 2006 [1]. This study has been technically validated by some proof-of-concept codes, but the most worrying results were only hinted at in [1] and have, to date, only been published in French [2]. This paper presents the latest technical results, for the first time in English. They have been updated since the last OpenOffice release (2.2.x).
The material presented here refers essentially to macro security and to the OpenDocument format (ODF) with respect to its built-in encryption and digital signature capabilities. These alone represent most of the OpenOffice security issues we have identified. Proof-of-concept code will not be presented here, since it is not relevant to the understanding of the article. Due to a lack of space, we have limited the extent of the technical details presented (file dumps in particular), however, they are all available upon request (for IT security professionals only).
Aside from ours [1], there have been only a few studies of OpenOffice security. The main ones are as follows:
In 2003, Rautiainen [3] presented a short analysis of macros with respect to OpenOffice versions 1.x.
In June 2006, Kaspersky claimed to have detected the first OpenOffice virus called StarDust. However, no technical evidence was available to support this claim, and OpenOffice.org later denied the self-reproducing nature of the malware.
In May 2007, a multi-platform OpenOffice virus, called BadBunny, appeared. This malware seems to be a direct illustration of the risk highlighted by our own work, in particular with respect to some advanced programming languages: Python, Js and Ruby.
In June 2007, a deep, comparative study on the security of both OpenXML and OpenDocument formats was published by P. Lagadec [4]. This study is a follow-up to [1] with respect to the viral hazard and information leakage in documents.
Apart from the search for software flaws, security analysis rarely considers functional evaluation, in other words the core algorithmic choices, or formal analysis: flow matrix, state matrix, protocol analysis. Unfortunately this is true for both open and proprietary software.
We will not recall the structure of the OpenDocument format here – a detailed description can be found in [1]. Let us just summarize that an OpenOffice document is in fact a simple, compressed ZIP archive. It is thus possible to decompress it and to access and manipulate all the different document components (data, meta-data, macros etc.) very easily. Our study was conducted for ODF documents under Linux, Windows and Mac OS. For the sake of clarity (use of command lines) and without the loss of generality, we present here the results for the Linux study.
Among all these components the most important one in terms of security issues is undoubtedly the manifest.xml file located in the META-INF directory of the ZIP archive. This file describes the complete document ODF structure and all the data which are essentially relevant to the different security functionalities: macros, encryption, digital signature etc. The other files are:
content.xml: this file is present in every OO document and simply contains the visible part of the document.
meta.xml: this file contains all the document meta-information (author’s data, access data etc.).
styles.xml: this file contains the document formatting options.
setting.xml: this file contains all the document configuration data (window size, printing parameters etc.).
Whenever one or more macros are used, a new directory is created:
./Basic: total 8 drwxr-x-rx 4 lrv lrv 138 Mar 2 01:47 Standard -rw-r—r— 1 lrv lrv 338 Mar 2 00:38 script-lc.xml ./Basic/Standard: total 16 -rw-r—r— 1 lrv lrv 350 Mar 2 00:38 script-lb.xml -rw-r—r— 1 lrv lrv 2049 Mar 2 00:38 a_macro.xml ./META-INF: total 8 -rw-r—r— 1 lrv lrv 1465 Mar 2 00:38 manifest.xml
The directory called Basic (we will consider macros written in the default scripting language, OOBasic) contains the complete macro file tree of the document.
In addition, the manifest.xml file has been modified to record the macros and their data (access path in particular):
<manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/Standard/a_macro.xml”/> <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/Standard/script-lb.xml”/> <manifest:file-entry manifest:media-type=”” manifest:full-path=”Basic/Standard/”/> <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/script-lc.xml”/>
There are a lot of possible scripting languages in which OpenOffice macros can be developed: OOBasic, JS, Python, Ruby etc. Whatever the language used, the general management scheme remains the same. Moreover, what has been presented for a single macro also holds true for complete libraries of macros [1].
Whenever a user applies a document password, the document is encrypted. Let us consider a document containing a single macro. All encryption technical data are included as properties within XML tags. The encryption algorithm is Blowfish in CFB mode, the keys are derived from the PBKDF2 key management protocol, while the hashing algorithm is SHA1.
As an ODF file is in fact a ZIP archive, it is necessary to define which files in the archive are encrypted and which are not. To see where the encryption takes place, let us compare the manifest.xml file of the reference_file_encrypt.odt (encrypted) and the reference_file.odt (unencrypted) files respectively. The following is a dump (excerpt) of the diff command between the two files:
< <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”content.xml”/> < <manifest:file-entry manifest:media-type=”text/xml” manifest:full- path=”Basic/Standard/HelloWord.xml”/> < <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/Standard/script-lb.xml”/> ----- > <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”content.xml” manifest:size=”2626"> > <manifest:encryption-data manifest:checksum-type=”SHA1/1K” manifest:checksum=”ITmRG2GO+QEChZSdWuHnELeNmoU=”> > <manifest:algorithm manifest:algorithm-name=”Blowfish CFB” manifest:initialisation-vector=”UnteGYIbs8Q=”/> > <manifest:key-derivation manifest:key-derivation-name=”PBKDF2" manifest:iteration-count=”1024" manifest:salt=”A1jwblqPdaNcWUpdgOF9Kg==”/> > </manifest:encryption-data> > </manifest:file-entry> > <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/Standard/HelloWord.xml” manifest:size=”339"> > <manifest:encryption-data manifest:checksum-type=”SHA1/1K” manifest:checksum=”zCCMsJxNl78Fzcpe/CnNEHgo4Bs=”> > <manifest:algorithm manifest:algorithm-name=”Blowfish CFB” manifest:initialisation-vector=”auXTuBEHXHQ=”/> > <manifest:key-derivation manifest:key-derivation-name=”PBKDF2" manifest:iteration-count=”1024" manifest:salt=”l/McRciiGElm7EIyxQDvRQ==”/> > </manifest:encryption-data> > </manifest:file-entry> > <manifest:file-entry manifest:media-type=”text/xml” manifest:full-path=”Basic/Standard/script-lb.xml” manifest:size=”350"> > <manifest:encryption-data manifest:checksum-type=”SHA1/1K” manifest:checksum=”kL8H/WhawMbDZeY47uBLZGY30qQ=”> > <manifest:algorithm manifest:algorithm-name=”Blowfish CFB” manifest:initialisation-vector=”5Y8OYH/JTkc=”/> > <manifest:key-derivation manifest:key-derivation-name=”PBKDF2" manifest:iteration-count=”1024" manifest:salt=”UIv7yfLKliAq8yN5ukoI3g==”/> > </manifest:encryption-data> > </manifest:file-entry>
All the archive files are encrypted, apart from the manifest.xml file. This is very surprising, since all the attacks we have noted are possible simply by editing and modifying this particular file.
A digital signature requires a certificate. OpenOffice relies on external components in order to obtain certificates. We will not focus on how to import those certificates here (see the OpenOffice inline help for more details), other than to say that we used X509 certificates for our research. We should mention that the ODF specifications [5] do not provide details about the use of digital signatures. We thus had to analyse how the signature is applied. For that purpose, let us consider an encrypted OpenOffice document containing a macro called ref_mac_enc_sig.odt.
The following is the most relevant data. More detailed data will be provided on request:
ZZR:~/Research/Analysis/OpenOffice.org/Work/Attaque_odf_190507/Struct_study
lrv$ unzip ref_macro_enc_sig.odt -d ref_macro_enc_sig_ext
Archive: ref_macro_enc_sig.odt
extracting: ref_macro_enc_sig_ext/mimetype
creating: ref_macro_enc_sig_ext/Configurations2/statusbar/
extracting: ref_macro_enc_sig_ext/Configurations2/accelerator/current.xml
creating: ref_macro_enc_sig_ext/Configurations2/floater/
creating: ref_macro_enc_sig_ext/Configurations2/popupmenu/
creating: ref_macro_enc_sig_ext/Configurations2/progressbar/
creating: ref_macro_enc_sig_ext/Configurations2/menubar/
creating: ref_macro_enc_sig_ext/Configurations2/toolbar/
creating: ref_macro_enc_sig_ext/Configurations2/images/Bitmaps/
inflating: ref_macro_enc_sig_ext/META-INF/macrosignatures.xml
inflating: ref_macro_enc_sig_ext/META-INF/documentsignatures.xml
extracting: ref_macro_enc_sig_ext/content.xml
extracting: ref_macro_enc_sig_ext/Basic/Standard/HelloWord.xml
extracting: ref_macro_enc_sig_ext/Basic/Standard/script-lb.xml
extracting: ref_macro_enc_sig_ext/Basic/script-lc.xml
extracting: ref_macro_enc_sig_ext/styles.xml
inflating: ref_macro_enc_sig_ext/meta.xml
extracting: ref_macro_enc_sig_ext/Thumbnails/thumbnail.png
extracting: ref_macro_enc_sig_ext/settings.xml
inflating: ref_macro_enc_sig_ext/META-INF/manifest.xml
ZZR:~/Research/Analysis/OpenOffice.org/Work/Attaque_odf_190507/Struct_study
lrv$We can see that two new files have been added into the archive: META-INF/macrosignatures.xml and META-INF/documentsignatures.xml. The manifest.xml file contains the relevant data for those two files:
<manifest:file-entry manifest:media-type=”” manifest:full-path=”META-INF/macrosignatures.xml”/> <manifest:file-entry manifest:media-type=”” manifest:full-path=”META-INF/documentsignatures.xml”/> ..................
The two new files are not encrypted. This point is essential to the understanding of the attack mechanisms of encrypted documents. The document.xml file contains the detailed data that are required during the digital signing process itself (not given here). Every file in the archive is unsigned while the macros’ signatures are declared within the macrosignatures.xml file. To be more precise, the digital signature is applied to any file containing or relating to macros [6], [7].
OpenOffice.org’s security is based on two essential mechanisms: password-based encryption and digital signature. Both aim to prevent illegitimate use or manipulation of a document. In the context of document malware, any weakness with respect to either of these mechanisms could be exploited in a powerful way to fool the user’s trust in cryptographic protection.
Since there are a lot of ways of using encryption and signatures to protect an OpenOffice document, we will use a formal graph-based approach to describe them all. Every node in our graph describes a user’s action. A given path in our graph describes a sequence of such actions to encrypt and/or sign a document. This is a very powerful approach for detecting security flaws – in other words, cases where the security mechanisms are supposed to have been applied while in reality they have not been (the document is not encrypted or not signed).
Our graph-based formalization aims to identify weaknesses in the signature process, in particular with respect to macros. To summarize, we will show that the signature of the document's visible content and the signature of the macros are mutually exclusive: we cannot sign them at the same time. Using technical examples, we will prove in subsequent sections that this constitutes a serious design flaw that can be exploited efficiently by malware.
Every node describes a possible status for the document:
D: modified document.
MD: modified document with macro.
ED: saved document.
EMD: saved document with macro.
SED: document is signed and saved.
MSD: document with a macro added after the document has been signed.
EMSD: document with a macro added after the document has been signed, but before the document is saved.
SEMD: signed and saved document with a macro.
The nodes are connected by labelled arrows. The labels describe a user’s commands/actions applied to the document:
add M: add a macro.
save: save document.
sig 1: sign through the File → Digital Signatures... menu.
sig 2: sign through the Tools → Macros → Digital Signature... menu.
sig 3: sign through the second bottom right box in the OpenOffice GUI.
The corresponding graph is depicted in Figure 1.
In Figure 1, we notice that the graph is divided into two connected components. The first sub-graph is made up of nodes MD, EMD and SEMD, while the second one contains nodes ED, SED, MSD and EMSD. This supposes two different possible uses of a digital signature that can be applied at any time in the life of the document. However, our experiments have proved that it may be quite different. Let us explain why.
When considering signature and encryption at the same time, our approach remains essentially the same. The set of nodes is generalized as follows:
D: modified document.
MD: modified document with macro.
(SE)MD: encrypted and saved document with macro.
S(SE)MD: signed, encrypted and saved document with macro.
(SE)D: encrypted and signed document.
M(E)D: a macro is added to an encrypted and saved document.
SM(E)D: a macro is added to an encrypted, saved and finally signed document.
S(SE)D: modified document which has been saved, encrypted and signed.
MS(E)D: a macro is added to an encrypted and signed document.
EMS(E)D: signed then encrypted document with macro.
We thus obtain the graph depicted in Figure 2. It is very powerful for identifying the potential misuse of digital signatures in OpenOffice. Such misuse could be by malware, as we will show in the next sections. Two classes of design flaw have been identified. The first class deals with the lack of built-in document integrity management. The second class refers to problems that may occur when macros and/or document are signed. We will not discuss the critical issue of trust macros. They are presented in [1].
The main problems with OpenOffice encryption and signatures do not lie in the cryptographic tools themselves but in their implementation and management. The main consequence is that a malicious program may be able to identify interesting blocks of instructions and thus adapt itself to the target document. This is particularly worrying with respect to macros which constitute execution points that can be subverted by a malicious program, despite the apparent use of a digital signature.
In this section, we will consider some cases where it is possible for malware to bypass a digital signature or to exploit it. All these experiments have been successfully carried out without causing any integrity violation alert and while preserving the document usability.
Let us first mention that the use of a digital signature can be identified within the archive in two ways:
An additional file, denoted documentsignatures.xml, is created in the META-INF directory of the archive.
An entry is added into the META-INF/manifest.xml file:
<manifest:file-entry manifest:media-type=”” manifest:full-path=”META INF/documentsignatures.xml” />
Let us first create a signed document containing a macro. Contrary to the user’s belief, the macro itself is not signed. As a consequence (see next sections), a malicious program can modify a macro without triggering any integrity violation alert, thus undermining the user’s feeling of security with respect to the digital signature.
The listing of the archive clearly shows that there is a signature which is applied to the document, but not to the macro. The META-INF/documentsignatures.xml does not refer to any macro signature:
ZZR:~/Research/Analysis/OpenOffice.org/work/Attaque_odf_190507 lrv$ unzip
doc.odt -d doc_dir
Archive: doc.odt
extracting: doc_dir/mimetype
creating: doc_dir/Configurations2/statusbar/
inflating: doc_dir/Configurations2/accelerator/ current.xml
creating: doc_dir/Configurations2/floater/
creating: doc_dir/Configurations2/popupmenu/
creating: doc_dir/Configurations2/progressbar/
creating: doc_dir/Configurations2/menubar/
creating: doc_dir/Configurations2/toolbar/
creating: doc_dir/Configurations2/images/Bitmaps/
inflating: doc_dir/META-INF/documentsignatures.xml
inflating: doc_dir/content.xml
inflating: doc_dir/Basic/Standard/Hello.xml
inflating: doc_dir/Basic/Standard/script-lb.xml
inflating: doc_dir/Basic/script-lc.xml
inflating: doc_dir/styles.xml
inflating: doc_dir/meta.xml
inflating: doc_dir/Thumbnails/thumbnail.png
inflating: doc_dir/settings.xml
inflating: doc_dir/META-INF/manifest.xmlIn this case, the signature is applied independently to the visible part of the document and to the macro itself. The only way to apply the signature to both of them simultaneously is to successively follow path sig2 and paths sig1 or sig3 in the graph shown in Figure 2.
To illustrate this, let us first sign the macro:
ZZR:~/Research/Analysis/OpenOffice.org/work/Attaque_odf_190507/App_dsig_doc_macro
lrv$ unzip doc1.odt -d doc1_dir
Archive: doc1.odt
extracting: doc1_dir/mimetype
creating: doc1_dir/Configurations2/statusbar/
inflating: doc1_dir/Configurations2/accelerator/current.xml
creating: doc1_dir/Configurations2/floater/
creating: doc1_dir/Configurations2/popupmenu/
creating: doc1_dir/Configurations2/progressbar/
creating: doc1_dir/Configurations2/menubar/
creating: doc1_dir/Configurations2/toolbar/
creating: doc1_dir/Configurations2/images/Bitmaps/
inflating: doc1_dir/META-INF/macrosignatures.xml
inflating: doc1_dir/content.xml
inflating: doc1_dir/Basic/Standard/Hello.xml
inflating: doc1_dir/Basic/Standard/script-lb.xml
inflating: doc1_dir/Basic/script-lc.xml
inflating: doc1_dir/styles.xml
inflating: doc1_dir/meta.xml
inflating: doc1_dir/Thumbnails/thumbnail.png
inflating: doc1_dir/settings.xml
inflating: doc1_dir/META-INF/manifest.xmlOnly the macro is signed. Let us then sign the document content itself. The listing clearly shows two different signature files:
ZZR:~/Research/Analysis/OpenOffice.org/work/Attaque_odf_190507/App_dsig_doc_macro
lrv$ unzip doc1.odt -d doc1_dir
Archive: doc1.odt
extracting: doc1_dir/mimetype
creating: doc1_dir/Configurations2/statusbar/
inflating: doc1_dir/Configurations2/accelerator/current.xml
creating: doc1_dir/Configurations2/floater/
creating: doc1_dir/Configurations2/popupmenu/
creating: doc1_dir/Configurations2/progressbar/
creating: doc1_dir/Configurations2/menubar/
creating: doc1_dir/Configurations2/toolbar/
creating: doc1_dir/Configurations2/images/Bitmaps/
inflating: doc1_dir/META-INF/macrosignatures.xml
inflating: doc1_dir/META-INF/documentsignatures.xml
inflating: doc1_dir/content.xml
inflating: doc1_dir/Basic/Standard/Hello.xml
inflating: doc1_dir/Basic/Standard/script-lb.xml
inflating: doc1_dir/Basic/script-lc.xml
inflating: doc1_dir/styles.xml
inflating: doc1_dir/meta.xml
inflating: doc1_dir/Thumbnails/thumbnail.png
inflating: doc1_dir/settings.xml
inflating: doc1_dir/META-INF/manifest.xmlA deeper analysis clearly shows that the two signature files have not been created at the same time:
ZZR:~/Research/Analysis/OpenOffice.org/work/Attaque_odf_190507/App_dsig_doc_macro/doc1_dir2/META-INF lrv$ ls -l * -rw-r—r— 1 lrv lrv 5875 Jul 12 14:45 documentsignatures.xml -rw-r—r— 1 lrv lrv 5657 Jul 12 14:30 macrosignatures.xml -rw-r—r— 1 lrv lrv 2602 Jul 12 14:45 manifest.xml
This constitutes a critical design weakness since the user must be aware of the fact that a specific signature process must be applied to sign OpenOffice macros. The main consequence is that most of the time it is possible to modify (infect) macros without violating the document’s integrity.
ODF is based on the XML technology. All the information is contained within XML tags, thus giving a semantic value to the information. All the XML tags are then organized within a tree structure that makes the extraction of the information far easier. These structures enable ODF to be formalized in a very powerful way by means of automata and language theories. For the sake of brevity we will not present the whole of our formalization work. The reader can refer to our technical report [8].
In order to identify all possible attacks that can be operated by malware against an OpenOffice document by exploiting integrity and/or signature management flaws, we have applied a formal model based on a graph-theoretic approach again. The graph is defined as follows:
Each node represents the document status at time t, before any action is applied to it.
The arrows represent the different possible attacks that can be performed once a given action (command) has been applied.
The node surrounding area defines a given feature for the document.
An action is applied to a node feature and thus defines which attack has been performed:
Add: add a property or a macro to the document.
Alter: modify a document property or component.
Cipher: the document is encrypted by using OpenOffice built-in tools.
Decipher: the encrypted document is deciphered by using OpenOffice built-in tools.
We thus obtain the attack graph depicted in Figure 3, which describes things at the lowest level. It is also possible to combine different document statuses to exhaustively describe all possible attacks at every possible level.
In part two of this article (which will appear in the October 2007 issue of Virus Bulletin) we will look at security issues in OpenOffice integrity management and draw conclusions about the overall security of OpenOffice.
[1] De Drézigué, D.; Fizaine, J.-P.; Hansma, N. In-depth Analysis of the Viral Threats with OpenOffice.org Documents. Journal in Computer Virology, (2)-3, 2006.
[2] Filiol, E.; Fizaine, J.-P. Le risque viral sous OpenOffice 2.0.x. MISC – Le journal de la sécurité informatique, vol. 27. 2006. http://www.miscmag.com/.
[3] Rautiainen, S. OpenOffice Security. Proceedings of the Virus Bulletin International Conference 2003.
[4] Lagadec, P. OpenOffice/OpenDocument and MS Open XML Security. PACSEC 2006 Conference. http://pacsec.jp/psj06archive.html.
[5] Open Oasis. OpenDocument Specifications v1.1. http://www.oasis-open.org/specs/.
[6] W3C. Spécification signature W3C. http://www.w3.org/Signature/.
