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.