|
Posted by Sebastian Gottschalk on December 24, 2006, 10:14 am
If you were Registered and logged in, you could reply and use other advanced thread options
MC wrote:
> 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?
Well, indeed exactly that. OpenOffice can go fine without proper validation
and normalization, but MS Office is at an immediate risk and OpenOffice can
be used to accomplish this process.
Obviously, if OpenOffice crashes, you'll never get the document into MS
Office in first place, if such a preprocessing is strictly required. :-)
>>> 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.
Is is not.
> 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.
Actually not. Most cases are null-pointer dereferences, which are not
exploitable.
> 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.
Well, you could simple remove the source of the 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.
That's a strange argument. After all, specifically this exploit we're
discussing can provably not be detected generically, so either the virus
scanners' signatures are incomplete or way too broad. So, however you try,
you won't be able to block such an attack vector.
> 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.
Eh, and what about exploits for webbrowsers then? It's not that such a
behaviour would be generelly avoidable. Not to mention how impractical such
a lack of features is.
Some people, on the other hand, don't use virus scanners at all.
>> And then, even afterwards, since MS Office is inherently insecure.
> Any person behind a PC doing anything is inherently insecure, too.
Nonsense.
> Any Internet connection is too, for that matter.
Also nonsense.
> Sebastian, I understand you seem to have a deep rooted hatred against
> anything Microsoft, but it gets the job done
Nonsense again. It doesn't even allow to store documents in a convient way,
neither does it work consistently.
> and is widely used, which will not soon change.
Indeed. But not because it works, just because the people using it are too
dumb to understand what's actually going on.
> Any program is as secure as the one operating/using or configuring it.
And even more nonsense. What do you think could proper configuration and
handling do to prevent various attack vectors based on known but unfixable
vulnerabilities. Best example: misusing MSIE as a webbrowser. Configure and
patch it as you like, you will be trivially exploitable.
> 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.
It's not about functionality. It's about the format itself.
>> 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.
Don't twist parsing and serialization. Parsing does enforce constraints by
creating new objects and filling them with the proper data, whereas
serialization gives you an improper constructor for possible invalid
objects.
The COM object is just the serializer and has nothing to do with the issue.
| 
XML site map