OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Office Worm?

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,


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:


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]