BadBunny? Only if you invite it in [LWN.net]

Office suite security is hard

Posted Jun 14, 2007 10:24 UTC (Thu) by eru (subscriber, #2753) [Link]

Making effective macro control polices is hard. Imagine a technical writer at a software firm who has to do a fact sheet for the company website, referring to some (confidential) design documents. One would want to remove the ability to connect to outside websites from the confidential documents (to prevent information leaks) while allowing an upload of the HTML code to the company external website.

Sorry, but I don't see what this example has to do with macros, unless you assume everything the technical writer does has to be mediated by the document macros, which would be just silly. The updating of the web sites are probably managed by some content management systems, having their own more or less friendly web interfaces (so it is no sweat for the writer to enter the document there when done), and enforcing their own security rules. I don't think anyone would trust information leak prevention based just on the document macros!

What I have mostly seen macroes being used (in the bowels of a large corporation) is in Excel-based apps, for example for creating a travel expenses invoice or a request for a new PC. These applets typically do not need external access. When they do, it would not harm usability if they asked. Something like a box saying "Macro send_travel_invoice requests to upload emp1234.odf to travels.mycompany.com. Allow? [Yes] [No] [Abort]". The box should come from the core of the application and be visually formatted in a way that no macro can replicate.

Office suite security is hard

Posted Jun 14, 2007 12:45 UTC (Thu) by hummassa (subscriber, #307) [Link]

Actually, I have tought it over and this is what I found: I understand why a macro language must be capable of reading stuff (even remotely, and it would be polite to ask the user for permission), of creating one (or two max) new document -- especially if the original document is a template, and of saving itself (or the created document, if the original document is a template) to the disk -- no overwriting allowed and certainly no transfer of macros allowed. But I can't find any reason why a macro language should be capable of writing anything.

Office suite security is hard

Posted Jun 14, 2007 14:35 UTC (Thu) by mrshiny (subscriber, #4266) [Link]

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.

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.

Office suite security is hard

Posted Jun 14, 2007 16:09 UTC (Thu) by MathFox (guest, #6104) [Link]

Sorry, but I don't see what this example has to do with macros, unless you assume everything the technical writer does has to be mediated by the document macros, which would be just silly.

One thing that can be done in a macro is currency conversion: a simple SOAP call to an currency website will do the trick. When one has the code to perform SOAP calls, one can generalize and use them for uploads of the document contents...

These applets typically do not need external access. When they do, it would not harm usability if they asked. Something like a box saying "Macro send_travel_invoice requests to upload emp1234.odf to travels.mycompany.com. Allow? [Yes] [No] [Abort]". The box should come from the core of the application and be visually formatted in a way that no macro can replicate.

Having the user confirm some actions is fine with me; but there are risks with confirmation boxes: Users may click "yes" without thinking when they see them too often; malicious macros may try to overwrite (part of) the box, presenting a different question to the user.

I repeat that macro control is hard; document control is hard.

Office suite security is hard

Posted Jun 14, 2007 20:03 UTC (Thu) by eru (subscriber, #2753) [Link]

So, no SOAP calls without asking the user.

Having the user confirm some actions is fine with me; but there are risks with confirmation boxes: Users may click "yes" without thinking when they see them too often;

True, but the alternative of quiet access is worse. I would also assume that writers of non-malicious macros for the system would try to minimize these questions by avoiding redundant accesses and doing as much as possible per requested access, since it is now somewhat "expensive". The system might also try to be intelligent, eg. not ask again about trying to load the same URL or file.

malicious macros may try to overwrite (part of) the box, presenting a different question to the user.

It should not be too hard for the suite to prevent this by forcing this security box to be always be on top of all other windows. The dialog box would also be invisible from the point of the macro language. Eg. an open("filename", "w") kind of operation would pop up the box without giving the macro language any change to prevent or modify it.