OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Office Worm?

    Posted 06-12-2007 12:48
    http://news.com.com/2100-7349_3-6189961.html
    
    Malicious software targeting OpenOffice.org documents is spreading
    through multiple operating systems, according to Symantec.
    
    regards
    
    -- 
    Dave Pawson
    XSLT XSL-FO FAQ.
    http://www.dpawson.co.uk
    


  • 2.  Re: [office] Office Worm?

    Posted 06-13-2007 09:40
    No idea why there are again news about the 4 weeks old "badbunny" news...
    
    See my answer here:
    http://blogs.sun.com/malte/entry/sb_badbunny_a_harmless_little
    
    Malte.
    
    
    -- 
    Malte Timmermann 


  • 3.  Re: [office] Office Worm?

    Posted 06-13-2007 10:33
    On 13/06/07, Malte Timmermann 


  • 4.  Re: [office] Office Worm?

    Posted 06-13-2007 11:16
    On Wednesday 13 June 2007 11:39:48 Malte Timmermann wrote:
    > No idea why there are again news about the 4 weeks old "badbunny"
    > news...
    >
    > See my answer here:
    > http://blogs.sun.com/malte/entry/sb_badbunny_a_harmless_little
    
    Just a little comment; the unix wisdom is to never ever allow code to be 
    shipped in the same container as data. This basic principle is violated 
    and thus you can wait for such problems.
    IMO its not just the media that makes an issue about this as the majority 
    of users will always answer 'yes' if they want to continue opening 
    something. So while your blog is technically totally correct, the media 
    is also totally correct that this is a real issue.
    
    Anyway, that's just how I look at it.  Take it however you want :)
    -- 
    Thomas Zander
    


  • 5.  Re: [office] Office Worm?

    Posted 06-13-2007 15:42
    Thomas Zander 


  • 6.  Re: [office] Office Worm?

    Posted 06-13-2007 16:42
    It's all about the balance struck between security and functionality. But I  am not a fan of "trusted computing" even if the model is refined to allow different levels of trust in embedded scripts. Combining code and data is inherently insecure and the fact that Microsoft does it is not in itself a defensible argument to me. Microsoft has a lousy and well-deserved reputation when it comes to software security. And the last time I checked, embedded Word scripts were still the largest single source of malware exploits on the planet, by far.

    The WordPerfect model is far more secure:

    1. No scripts embedded in documents, ever.

    2. Scripts can not be triggered from the default WPD format.

    3. Scripts can be triggered from WPT template files on enabled events only.

    4. Script directories are remappable to non-default URIs from within the application or via group policies.

    It works. At least as of 2001, there had never been a WordPerfect document-based virus or worm in the wild. (I haven't checked since then, but suspect it is still true.) This is not to say that it is impossible to create such malware, but it is far more difficult without the ability to embed executable code in a document. There is still an element of trust involved when sharing scripts, but in my book forcing a deliberate user decision to install software is way ahead of any option that allows one-click execution of code not previously installed to the system. IMHO, if a user isn't wise enough to manually install a script, the user isn't wise enough to be trusted with a one-click method of launching embedded scripts whether different trust levels are assigned or not.

    Best regards,

    Marbux


    On 6/13/07, Nathaniel S Borenstein <nborenst@us.ibm.com> wrote:
    Thomas Zander <zander@kde.org> wrote on 06/13/2007 07:15:34 AM:

    > Just a little comment; the unix wisdom is to never ever allow code to be
    > shipped in the same container as data. This basic principle is violated
    > and thus you can wait for such problems.
    > IMO its not just the media that makes an issue about this as the majority

    > of users will always answer 'yes' if they want to continue opening
    > something. So while your blog is technically totally correct, the media
    > is also totally correct that this is a real issue.

    Certainly it is a real issue, though it is one that affects MS Office no
    less (and probably more) than Open Office.  The basic problem is very deep.

    Users expect to be able to construct extensions to documents and send them
    along with the documents.  However, most documents are transmitted without
    any authentication or even integrity checking.  There's not going to be a
    lot of security available as long as both of these statements are true,
    using conventional programming or scripting languages,

    There is another possible approach, which involves constructing and
    standardizing a programming language that is designed for different levels
    of trust in the sender, including no trust at all.  With such a language,
    you can allow a reasonable class of "harmless" extensions even in untrusted
    scripts, while using authentication mechanisms (such as PGP or S/MIME) to
    offer more capability to trusted scripts.

    I've been a fan of the latter approach since the early 90's, when I
    developed several languages that had these characteristics.  (The languages
    were geared for email and MIME structure, but could work similarly for
    general documents and XML structure.)  For those who are interested, you
    can read about them at:

          http://www.guppylake.com/~nsb/pubs/safe-tcl.pdf
           http://www.guppylake.com/~nsb/pubs/CSCW-ATOMICMAIL.txt

    Standardizing one or more such languages would be a major contribution, but
    also a whole lot of work.

    Finally, just a brief comment on this line from Malte's blog:

    > Users shouldn't run macros from unknown sources, same like they
    > shouldn't run any programs or other scripts from unknown sources.

    Of course they shouldn't.  But they do, and they will.   We'll never
    perfectly train our users, but we could substantially reduce their
    opportunities for inadvertently harming themselves.  -- Nathaniel