image Home       image Fowles,       image Fitzgerald,       image r04 06 (9)       image R 22MP (3)       image 45 (3)       

Linki

[ Pobierz całość w formacie PDF ]
J Comput Virol (2006) 2:187–210
DOI 10.1007/s11416-006-0020-2
ORIGINAL PAPER
In-depth analysis of the viral threats with OpenOffice.org documents
David de Drézigué
·
Jean-Paul Fizaine
·
Nils Hansma
Received: 10 April 2006 / Revised: 20 June 2006 / Accepted: 4 July 2006 / Published online: 1 August 2006
© Springer-Verlag France 2006
Abstract
This paper presents an in-depth analysis of
the OpenOffice suite (release 2.0.3) with respect to viral
threats, independently of any software flaw or vulner-
ability. First we will identify, then analyse the differ-
ent potential viral vectors of OpenOffice.org v2.0.3. Our
examination applies to win32 and Unix-like platforms.
For each identified vector, a detailed study will show
to which extend the infection is possible. From then on
we will define the solutions in order to maximize Open-
Office.org security in the production field as well as in
the office tools at the administration level.
a subject liable to concerns. On top of issues related
to information leaks [1], the risk linked to macro-virus
has been a concern to the end-users [3] since the
Con-
cept
macro-virus in 1995. The presence of macros in an
office document is henceforth identified by the risk –
at least potential – of macro-virus. Even though the
antiviral offer enable to fight efficiently against the well-
known macro-viruses or the identified techniques, it still
remains pretty easy to conceive an undetected macro-
virus by the current antivirus.
The development and the release of OpenOffice free
software suite [11] for a few years seemed to inspire new
hopes – and maybe hypes – as far as security linked to
office documents was concerned.
The adoption of this suite by several countries and
by foreign armies in particular (Singapore in 2006, the
French Gendarmerie in 2005), some institutions, some
universities… [12] led the media to see a sign of greater
security into it, furthermore it costs almost nothing. The
certainty of a greater security towards the viral risk has
become an overspread feeling in the freeware commu-
nity as much as in the mind of several end-users. The
consequence is that the latters forget the security behav-
iour and reaction – and more particularly the caution
against the presence of macros – when opening office
documents. What should one think about the security
of OpenOffice suite regarding macro-viruses? Myth or
reality?
The OpenOffice suite, just like its commercial equiv-
alent, contains an inserted development environment
around several programming languages. The language
OoBasic – the best known – has replaced the
Visual
Basic for Applications
for macros writing. But other
programming languages, more powerful than the plain
OoBasic allow more sophisticated developments than
Keywords
Malware
·
Macro virus
·
Document
malware
·
Self-reproduction
·
Security Policy
·
Antiviral Policy
1 Introduction
For many years, the software sector of the office suite
has been dominated by the supremacy of the Micro-
soft Office suite. This suite has succeeded in offering the
end-user a powerful and ergonomic environment. Nev-
ertheless, the security of the products making up this
suite (
Word
text processing,
Excel
spreadsheet, presen-
tation software such as
PowerPoint
…) has long been
B
D. de Drézigué
N. Hansma
Ecole Supérieure et d’Application des Transmissions,
Laboratoire de virologie et de cryptologie,
BP 18, 35998 Rennes Armées, France
e-mail: labo.virologie@esat.terre.defense.gouv.fr
D. de Drézigué
·
J. -P. Fi za i ne (
)
·
N. Hansma
Ecole des Systèmes de Combat et Armes Navals,
Centre d’Instruction Naval,
BP 500, 83800 Toulon Naval, France
·
 188
D. de Drézigué et al.
the plain macro writing, no matter how complex they
may be. These different kinds of execution contexts
seem to argue in favour of the possible uses of macro-
viruses for OpenOffice. Such a possibility has been
previously evoked by Rautiainen [14] but this author
considered only a few security aspects. Moreover, Rau-
tiainen’s paper dealt with the OpenOffice version 1.0.x.
The OpenOffice release 2.0.x contains many more pow-
erful capabilities as far as infectious threats are con-
cerned.
This article introduces the real security analysis of
the OpenOffice suite with regards to viral threat is con-
cerned. Independently of any software vulnerability, the
results show that not only can this suite not be consid-
ered immune tomacro-viruses but above all, considering
the current development condition of this suite, the later
shows a higher rate of hazard than for her commercial
competitor. In other words, any hazardous behaviour
from the end-users may lead to serious outcomes over
information security system. This security analysis has
been recognized by the design and the testing of several
operational
1
viral strains demonstrating that this risk is
truly real and is giving cause for concern. Therefore any
security policy should seriously consider the viral risk
linked to this suite.
This article is partly based on [2] and is organized as
follow. Sect. 2 will present the main identified vectors
of potential infections for this suite, through a step by
step analytic approach. Sect. 3 will deal with the operat-
ing of these infection vectors through malevolent codes.
Finally, Sect. 4 will, on the one hand, ponder over the
viral risk attached to the OpenOffice suite, and on the
second hand, will introduce the algorithmic of some few
viral stocks that have been developed and tested for
validation purposes.
Disclaimer:
Developing proof-of-concepts is not a goal
in itself. It remains the only scientific way to prove if a
viral risk exists or not. Deficiency of antivirus may result
in human casualties or even deaths, lost of jobs... when
considering critical or very critical systems. Consequently
any serious protection cannot rely only on the deployment
of an antivirus, whatever may be its efficiency. No serious
security policy of such critical systems could accept secu-
rity enforcement without a proactive research including
proof-of-concept developments. This study has been per-
formed in the strict respect of the different existing laws.
The source codes which have been developed will neither
be disclosed nor published. Only reknowned and strictly
identified IT security professionals are eligible for freely –
and without any compensation of any kind – accessing
these source code provided that they fill an application
form to the Virology and Cryptology Laboratory of the
Army Signals Academy.
2 Identification of the potential infectious vectors:
OpenOffice.org V2.0.x analysis
First we will analyze the file format in order to know
its structure as well as its organization; which enable us
to infer the way we will be able to manipulate it. Sec-
ondly, we will analyze the installation, the configuration
so as to identify the potential propagation vectors for all
the well known viral infection technologies [4]. We will
define a potential propagation vector as follows:
– an automatic, scheduled or event-related execution
point;
– use of a regular human task;
– execution transfer, or process creation;
– weak environment identification: configuration of
the suitable application for the malevolent code
execution.
2.1 The OpenDocument V1.0 file format
This file format is a standard introduced byOasis-Open,
2
in 2005. It has recently adopted by ISO/IEC in May
2006, and called ISO/IEC DIS 26300, on the demand
of the European Commission [8] with the agreement
of SunMicrosystems and Oasis-Open. This is a file for-
mat based on the XML technology. It can be used with
all kind of tools handling this technology. OpenDoc-
ument supports various other kind of document like
database, diagrams, drawings, slideshows and spread-
sheets. This file format is also supported by a num-
ber of various applications: AbiWord, Knomos, Koffice,
OpenOffice, Scribus StartOffice and recently by Ibm
Workspace but not with Office Microsoft. State of Mas-
sachusetts has first adopted this format, and recently
Europe as standard exchange document format. The
structure and organization of the file depend on the pat-
tern specified by Oasis Open
3
[9]. We are presenting its
main features that show specific relevance in the chosen
context.
2
http://www.oasis-open.org
3
A pattern is a document that describes the creation of an XML
file format.
1
These strains have been developed for the
Writer
component
but are easily transposable to other software components of the
suite.
 In-depth analysis of the viral threats with OpenOffice.org documents
189
2.1.1 Analysis of a blank document
It is regarding the XML files format that the official liter-
ature [9, Chap. 2] provides a very useful understanding
of an XML OpenOffice.org document structure.
The “file” command on our blank reference file, points
out that the file is a ZIP format archive. We notice that
the archive is neither compressed nor protected by a
password. This will not prevent an archive infection. The
extraction of the archive is usually carried out with the
help of any utility compatible with the ZIP format. Thus
here follows the content of our blank reference file:
2.1.2 Analysis of a user document
The reference test file is a simple document which con-
tains styles, a rather important number of pages and
its own text layout information. At this stage, neither
macros, nor other objects (OLE objects, links, sound
or video data...) or images are present yet. We consider
again the previous analysis protocol. Let us compare this
present user document with the blank reference one.
We find again the same files and directories. Only the
size of files
content.xml
and
setting.xml
have changed.
Whereas the reference file has a size of 147,332 bytes,
the user file has a size of 147,470 bytes. However the
corresponding archives differ from one another in size
of only five bytes. Moreover, the content of
setting.xml
file has changed. To make things clear, the content of
the user document archive here follows:
The META-INF directory contains a
manifest
XML
format file [9, Chap. 17]. The latest classifies the paths
towards other XML files of the archive as well as infor-
mation describing the archive as the encoding algorithm
along with its parameters, the checksumpasswords algo-
rithm as well as the checksum value. The directories

Configuration2
” and “
Pictures
” are empty. By lexico-
graphic order:

content.xml
: this file is common to all types of Open-
Office.org documents. It can contain the following
items: scripts, font settings, automatic style and doc-
ument body.

meta.xml
: this file contains the document meta-
information (author, date of the last action…),
Let us now compare both archive sizes:

styles.xml
: specifies the style used for the document,

setting.xml
: points to the configuration such as the
programapplicationwindow size or to printing infor-
mation.
 190
D. de Drézigué et al.
2.1.3 Comparison to a document with macros
In a macro-virus context, the size of such a virus is lia-
ble to have a rather large size ranging froma few bytes to
hundreds of kilobytes. Its final size will greatly depend
on its sophisticated level and of the script language that
has been used to implement it. Let us suppose that the
viral code has an average size of 10 Kb. Let us suppose
in addition that the resulting archive (that of an infected
file) has increased of only one Kb for every 500 added
bytes of virus. If we consider, in a first approach, that the
size linearly increases,
4
thenwe notice that consequently
the archive’s size has increased of 20 Kb. From an oper-
ational point of view, this size increase is rather limited,
not to say negligible. This feature enables the design of
very large-sized viral codes for OpenOffice.org whithout
making the final size of the archive explode. This fact
is worth considering as far as viral stealth features are
considered, especially when infecting large-sized docu-
ments.
Let us now insert a macro in the user document we have
just considered. The name of this macro is
dicOOo
and
belongs to the standard macros library (installation of
a dictionary). We notice that a new directory has been
created (output extract produced when unzipping an
archive):
2.1.4 Storage structure of macros in libraries
This new directory contains the whole organisation of
macros into directories. The new file in this file sub-tree
corresponds to the new macro itself. The
manifest.xml
file has been modified in order to declare the presence
of any macro and to setup the document accordingly.
The set of all macro pathes have been added.
Libraries of macros are stored in the
Basic
directory. A
library is materialized by a sub-directory which has the
same name as the library itself. This sub-directory con-
tains the macros which are linked to this library. More-
over, a library entry is created in the
“script-lc.xml
file
and macros themselves are listed in the
script-lb.xml
file.
During this in-depth study, we easily manage to add,
erase or modify one or more libraries by means of sim-
ple command lines. When infecting macros, any efficient
malware attack must modify the files
script-lc.xml
and
script-lb.xml
, in order to avoid error on document open-
ing. By considering this, we successfully manage to <<
play >> with the general structure of OpenOffice.org
documents, without prompting any alert. The probably
most surprising issue comes from the fact that any absent
macro (when deleted for instance) does not cause any er-
ror when opening the document. When editing macros,
the deleted macro is listed but cannot be executed since
it does not contain any code. OpenOffice considers only
the content of the files
script-lc.xml
and
script-lb.xml
and
does not make any consistency checking.
Here follows the corresponding dumps (normal li-
brary).
The code of any macro is located between the two fol-
lowing XML tags.
Here are located all the informations required to per-
form an infection of any macro. Let us notice that it
is possible to change the macro language. An efficient
attack will usefully consider this characteristic.
The size of
content.xml
and
manifest.xml
have
increased whereas for the two relevant archives (with
and without macro), a significant increase of size has
been noticed (1,779 bytes). This corresponds to the addi-
tional meta-information which result from the macro
creation.
– Here is the
Basic
directory content of an Open-
Office.org document:
4
The experiments we have conducted have shown that this prop-
erty did hold most of the time.
 In-depth analysis of the viral threats with OpenOffice.org documents
191
Let us analyse now a protected document with a
macro. In some frequent cases, we have noticed some
worrying algorithmic problems, as far as password pro-
tection is concerned.
5
In these cases, the listing of the rel-
evant archive is the same before and after the protection.
Let us have a more particular look at the macro direc-
tory. We notice a very important fact: there is strictly no
difference at all between the corresponding macro files
(documents with and without macros). Consequently,
we can deduce that, in these cases, despite the pro-
tection through passwords, the code of macros remains
unprotected (unencrypted). This implies – and we will
later confirm it with the proof-of-concepts codes we
have developed – that infecting a password protected
document is as easy as for unprotected ones. The integ-
rity of some files in an archive is not taken into
account, even by password protection. We manage to
replace an encrypted macro with an unencrypted one.
For that purpose, we modify the following data: META-
INF/manifest.xml, Basic/Standard/
– Here is listed below the
script-lc.xml
content (two
macro libraries):
>
and Basic/Standard/script-lb.xml. The password is still
required at document opening while the new macro is
executedwithout any security warning – by using trusted
macros (see Sect 4.2).
The analysis of the
META-INF/manifest.xml
enables
to get some information about the OpenOffice encryp-
tion which is moreover described in full in [9].
<
macro_name.xml
– Content of the
script-lb.xml
file (information about
the content of the
Standard
library):
– Only the following files have been encrypted:
con-
tent.xml, style.xml
and
setting.xml
.
– The encryption algorithm is Blowfish [17] in CFB
mode. The encryption uses a different seed and ini-
tialisation vector (IV) for every different file to pro-
tect. Files are compressed before encryption. The
initialisation vector is an arbitrary 8-bytes sequence
which is base-64 encoded.
– Encryption key is built directly from the password
which is provided by the user. The key setup algo-
rithm is the PBKDF2 algorithm [16] (16-bytes salt,
base-64 encoded, 1024 iterations). Finally, the de-
rived key is prepended to the encrypted text.
– The document integrity is secured by means of the
SHA-1 hash function [7] but there is no integrity
checking for the macros which thus can be modified
without prompting an alert to the user.
Let us recall that we experiment the fact that it is
possible to add a macro or even a whole library into an
OpenOffice.org document without prompting any alert.
A very interesting attack scenario then consists in call-
ing or manipulating any newly added (by a malware)
macro directly from another infected macro. Moreover,
it is possible to load a library that OpenOffice cannot
access directly [10, p. 764].
2.1.5 Password protection
Let us now suppose that the user has protected his docu-
ment with a password (read and/or writemode). The rel-
evant OpenOffice.org component will deny any access
to the document unless the correct password is given
upon request.
Comparison of the
content.xml
files (for protected
and unprotected documents) shows an unquestionable
difference. However, the archive content is neither en-
crypted nor protected by the password that has been
used when saving the document. Only the
content.xml
file is encrypted.
5
We will not explicit these cases in order to limit their potential
exploitation by attackers. We have contacted OpenOffice devel-
opers in order to correct these security problems and a joint work
has been initiated. We have noticed a very great reactivity.
  [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • zolka.keep.pl