Recent word exploit also causes problems in OpenOffice

Exploit for Word also works with OpenOffice

The exploit for the third unpatched security hole in Word reported last
week also works in OpenOffice 2.1. If a prepared Word document is opened
in OpenOffice Writer under Windows XP SP2, Writer crashes. The dialogue
for document recovery then appears. Under Linux, the application also
crashes, prompting the message that the main memory is full.

It has not yet, however, been demonstrated that code can be injected via
this weak point in OpenOffice. But there are unconfirmed reports that
this is possible. In contrast, the hole in Word is reportedly already
being actively used to infect systems. In a test, Kaspersky's virus
scanner detected the exploit and deleted the file. But not all virus
scanners provide protection from such attacks, as a scan for the
malicious code at Virustotal showed this week.

Not all virus scanners recognize the seven day old exploit.
As of 19-12-2006, the following AV suites detected the exploit:
AntiVir, BitDefender, ClamAV, Fortinet, Ikarus, Kaspersky, McAfee,
Microsoft, NOD and Panda.

Others soon to follow, but extra care should be taken in the meantime.

Related links
http://www.heise-security.co.uk/news/82548
http://blogs.technet.com/msrc/archiv...y-reports.aspx

Sebastian Gottschalk wrote:
> Nonsense. MS Word is insecure by design, so every untrusted document has to
> be validated and normalized before opening it. (Common tools for doing so
> are OpenOffice and AbiWord...)
My point being that OpenOffice crashes upon opening of the document,
despite the validation. And my comment was about virus scanners picking
it up, and since it's a new exploit, more AV suites will soon follow in
detection of this malicious code, but that caution is needed in the
meantime. So you probably misread what I was getting at.

I'm even willing to go further. If you -must- distribute a document with
layout and graphics in place, do so in a portable format that can be
opened on any system, like RTF, OpenDocument (which is an ISO standard
if I recall correctly) or PDF, to name a few, depending on your needs.
I'm quite opposed to the widespread use of Word documents as general
text processing format to be sent to others. Not to mention using Word
documents as e-mail bodies like some people do, often not even realising
it can't easily be opened or read on, say, a Linux system...
Simply put: too many bells and whistles to the format which causes the
potential risk of the document viruses and exploits we've seen over the
years; this one no different.

I thought this was of note since the exploit apparently uses a common
component that is -not- specific to Microsoft Word, and also crashes
OpenOffice. A warning in place for people that will likely have multiple
documents open that, with a crash of the program, may lose data.

But no matter how much you hate Microsoft, the Office suite is in use by
quite the chunk of the administrative offices around the world, so you
can expect the format to be widespread (since a lot of people don't seem
to know what "save as..." does, or what format to choose instead of the
default in that case)

MC

Sebastian Gottschalk wrote:
>> My point being that OpenOffice crashes upon opening of the document,
>> despite the validation.
> OpenOffice doesn't even know the intimate details of the format, thus the
> validation is incomplete by import alone, completed at export.
So why was your argument that it would be validated and normalized then?

>> And my comment was about virus scanners picking
>> it up, and since it's a new exploit, more AV suites will soon follow in
> And yes, that's nonsense, since virus scanners can't stop any exploitation
> path.
Actually, it is an exploit in the program, regardless of which path is
used to load the document. If you have a document on disk, and load it
into OO, it -will- crash writer. This crash is -possibly- an entry point
for an exploit. I am not familiar with the intimate details of the
exploit myself, but in most cases, making a program crash due to an
unhandled exception gives room for the insertion and execution of
arbitrary code in memory.
Virus scanners are always the combatants of symptoms, they always have
been and always will be. Of course it is best if the source is fixed,
whether that is hardware, software or wetware, but in practice you just
can't always do that or assume it can be done quickly enough to not make
it a problem.

If the exploiting document is loaded directly from a web source into
> memory (storing it into the browser cache in parallel, which can be
> detected), then it's simply too late. You will need caution until it's
> patched.
This is a good reason why I don't like web browser plugins for this kind
of file. It is also hard to intercept by an AV scanner for this very
same reason, unless the actual data streams when browsing are scanned
on-the-fly. Which means that if this becomes a real concern, that people
should just stop using plugins that read the data directly, and instead
use the conventional way of saving a document to disk and open it with
the associated program instead of the browser.

> And then, even afterwards, since MS Office is inherently insecure.
Any person behind a PC doing anything is inherently insecure, too. Any
Internet connection is too, for that matter.
Sebastian, I understand you seem to have a deep rooted hatred against
anything Microsoft, but it gets the job done and is widely used, which
will not soon change. Leaving out the "additional" remarks thrown in
like this would make for a much nicer discussion environment in this
newsgroup. Any program is as secure as the one operating/using or
configuring it.

>> Simply put: too many bells and whistles to the format which causes the
>> potential risk of the document viruses and exploits we've seen over the
>> years; this one no different.
> It's an inherent issue. You don't need any experience to see why it's a
> problem.
Indeed. That's why I suggested to use other formats if you don't need
the extra functionality that comes with this kind of problem.

> The problem is the format design: basically it's a serialized memory dump.
If you say so. I find this a strange concept. A memory dump from one
program or even program version would be, by definition, incompatible
with another program or version.
However, since you describe the filtering through a COM object, I don't
see how this is different from any other file format being saved from an
in-memory state through a parser to write out a structured file. An
image when stored in memory, to name one thing, is different from what
is written to disk, but it is still a serialized memory dump that gets
restored when loading the file through the reverse process.