Office suite security is hard [LWN.net]

Office suite security is hard

Posted Jun 14, 2007 14:35 UTC (Thu) by mrshiny (subscriber, #4266)
In reply to: Office suite security is hard by hummassa
Parent article: BadBunny? Only if you invite it in

You answered your own question: if the macro in question is in a template, the macro may need to automatically create new documents based on the template. It's not unimaginable that a generated document might itself contain macros, for the same reason that any document already contains macros. Finally the macro language needs the ability to write these files to disk somehow. As for what kinds of files the macro should be able to use, I can think of several reasons why a macro might want to write a plain-text file, or even a binary file. Exporting spreadsheet data in some custom format required by a certain application comes to mind.

As for limiting the number of files created, this reduces the utility of the macro for users with larger needs than yours. You might be generating a mailing to thousands of customers and using a macro to do that.

Personally I think the bigger question is why the macro permissions are not more fine-grained. Javascript, by default, can only manipulate the DOM of the current document, and make HTTP requests back to the originitating server. If you need a JS script that can write files, it needs to be signed and the user has to grant it permission to write files. Seems like a reasonable restriction to me. Java has a similar policy with Applets; there are ways to grant applets more permissions, but core features such as writing files are not available by default. Considering that Sun owns OO.o and Java, I'm surprised they haven't figured this out already.

(Log in to post comments)

Office suite security is hard

Posted Jun 14, 2007 19:47 UTC (Thu) by iabervon (subscriber, #722) [Link]

Wouldn't it make more sense for an export macro to generate a blob of binary data, and activate the "Save As..." menu item? Even if it's not malicious, macro-directed writing to files has a substantial risk of overwriting something the user wanted to keep, or, at best, leaving the result somewhere that the user will have to search for it. And macros that download data files probably ought to pass them off to the program to store as appropriate.

Office suite security is hard

Posted Jun 15, 2007 12:21 UTC (Fri) by hummassa (subscriber, #307) [Link]

"if the macro in question is in a template, the macro may need to
automatically create new documents based on the template" -- Ok, that I
think I have already said it would be permitted.
"It's not unimaginable that a generated document might itself contain
macros, for the same reason that any document already contains macros" --
From the point of view of security, yes it is unimaginable that
non-template documents contain macros.
"Finally the macro language needs the ability to write these files to disk
somehow" -- I suggest opening the 'save as' dialog, WITHOUT file name, and
disalowing overwriting entirely.
"As for limiting the number of files created, this reduces the utility of
the macro for users with larger needs than yours. You might be generating
a mailing to thousands of customers and using a macro to do that" -- and
what is the problem of accumulating all the output (if it has to be saved
at all) in one single file?
"Personally I think the bigger question is why the macro permissions are
not more fine-grained [...] Considering that Sun owns OO.o and Java, I'm
surprised they haven't figured this out already." -- because Office suite
security is still not widely studied. That's exactly the point of my post:
things like overwriting files and creating documents should be HARD to do
in an Office suite macro environment (unless some hard,
non-easily-automated configuration is required for that exact document by
the user -- and this should come after)

The operations/limitations I described (*) blanketed every single system
implemented in macros I have knowledge (and I work with a very complex
workflow system made 60% in Word macros) and would make close to
impossible to make macro worms/viruses.

(*) trying again:
templates creating a limited number of new documents,
templates creating at most one new template -- and even this I deem
fairly dangerous and not really necessary,
documents cannot have macros,
no automated writes (every time a new file is created, Save As dialog is
shown without a default name),
no overwrites at all.

Mind you, this means a template can create a mailing list, print it,
export the whole mailing list to PDF, or e-mailing each of the recipients
in a database -- all operations that do NOT require it to save/overwrite
anything. This means if you have to have a form to be filled and some
processing/result of that form (even if you have to access the web/ a
database/ another document in the LAN for it), it's OK -- as long as your
macros are in the form template. Said processed form can be then printed,
exported, e-mailed, posted to the web, anything -- but not written over
another (existing) file.

Office suite security is hard

Posted Jun 16, 2007 15:09 UTC (Sat) by mrshiny (subscriber, #4266) [Link]

using "save as" to determine the filename for saved files works in simple cases but wouldn't be effective in cases where hundreds of documents need to be generated. As for a macro overwriting files that a user wanted, or putting files in a place a user can't find, for the use-case I had in mind the location would be well-known and hundreds of generated documents would have generated filenames to help ensure uniqueness. Is the process fool-proof? For those two requirements it can be, depending on the author of the macro. And if a random user is generating hundreds of documents on his own computer and doesn't know where the files should go, the macro can allow the user to choose a directory and optionally choose a filename pattern. This are not big problems and it's very common for people to want to generate lots of files all at once. The filename/location usability issue has nothing to do with macros in this case.

As for accumulating all the output of a macro and saving it to a single file, I doubt that would work for large workflows. I used to work for a company that made document automation software using Microsoft Word and Word was unable to handle very large documents or large numbers of open files. I doubt Openoffice can scale to the volumes my customers needed either; consequently the documents have to be worked on in a one document per file at a time fashion.

As for your comment about non-templates never needing macros, I'd have to say that I partially disagree. I can think of hundreds of examples where spreadsheets may require macros. However where I will agree is that these macros are not likely to require dangerous operations.

You said that office suite security is not widely studied. However there are plenty of models to examine that give us a very good idea of the kinds of things office suite security should have. Obviously HTML+Javascript is the best example; browser makers manage to do a fairly good job sandboxing javascript... there are implementation flaws, but the model is reasonably sound. Furthermore Microsoft has studied the macro issue extensively and recent versions of Office deprecate the old macros in favour of .Net macros; these are exactly what I think Sun should implement, because the .Net VM supports the use of a permission manager to control what operations code can perform. Java supports this as well and has for years in the form of applets. There is no reason that the "API" of an office suite can't be simply categorized into "dangerous" and "believed non-dangerous", and the APIs which are dangerous require signed scripts or user approval or both. Sun already provides exactly this model with Applets and browsers have provided this model with javascript. If OpenOffice can't do this, it needs to catch up to 1997's security models.