Weekly Edition
Return to the Security page
| |||||||||||||
OpenOffice.org security concernsOver the past month, there have been various news articles regarding OpenOffice.org (OO.o) security, particularly in comparison with its main closed source rival, MS Office. Some articles have depicted OO.o as vastly less secure based on research by an organization within the French Ministry of Defense. The situation is a lot more muddled than that and unfortunately, because details are hard to come by, it is difficult to fully evaluate the threat. The original article (in French) described a meeting where a report on OO.o security was shared with various French ministries. The report supposedly claimed that for some threat types, OO.o was more vulnerable than MS Office. Another article, with the provocative title OpenOffice.org less secure than Microsoft Office?, appeared shortly thereafter and fanned the flames, positing that the city of Paris and other OO.o users in France might reconsider their tool choices based on the report. A 'response' to the articles appeared on the OO.o website but did little to shed any light. It was claimed that it would be inappropriate to respond to a "leak from a private meeting" followed by some platitudes about security response by the OO.o team. Perhaps unsurprisingly, there was no confirmation or denial of the security issues. Shortly thereafter, Sun's Technical Architect for OO.o, Malte Timmermann, posted some information in his blog. He and the OO.o team in Hamburg spoke with Eric Filiol, one of the authors of the report, to discuss the findings. According to Timmermann, there were three issues, only one of which was truly a bug and even it was "not really a security issue." All of the issues seem to revolve around macros and how they are trusted both by users and by the software itself. Timmermann followed that up with another blog posting this week that gave a few more details. He claims that the original report (which is to be published in the Journal in Computer Virology) was "conceptual problems only, not about security exploits." The problems described all stem from an initial infection which happens via a user running untrusted code (either as a regular executable or as a macro in an untrusted document). Timmermann rightly points out that if a user runs code from untrusted sources, changing security settings for OO.o may well be the least of their worries. Untrusted code can do anything that the user running it has permission to do and that has nothing to do with what OS or office suite you happen to be running. It may be that users still need additional training so that they do not run macros from untrusted documents, but OO.o does provide a security warning before executing them. He also points out that both MS Office and OO.o provide a powerful scripting language that has access to the underlying system and that threats from running untrusted macros are likely to be similar for both office suites. So, depending on who you listen to, there are either some serious (but largely unspecified, at least as of yet) security issues with OO.o, or there are not. OO.o is more at risk for these (again unspecified) risks than MS Office or it is not. There is at least one bug that Timmermann mentions, but it has not yet been fixed (based on the most recent security fix for OO.o which was 29 June, well before this information came to light). It is not clear why there is so much murkiness surrounding these issues. Is it due to 'responsible' disclosure policies? Or are folks unwilling to disclose the most interesting pieces of the journal article before it is published? Around the time these issues were being discussed, there were a number of 'zero-day' exploits in the wild against various MS Office formats. It seems likely that some of the technical press wanted to present 'balanced' coverage and seized on this issue to offset the negative press about MS Office. From the limited details we have seen so far, this particular report about the security of OO.o would not seem to merit the coverage that it has gotten. (Log in to post comments)
OpenOffice.org security concerns Posted Aug 17, 2006 9:17 UTC (Thu) by bockman (guest, #3650) [Link] IMO all-powerful macros inside documents are a really BAD idea.Many of the desktop security problems come from the applications that blurry the distinction between programs and data, so that one thinks that he is opening a document (or a picture or an htlm page ) and instead he is running a program. Word-processor macro languages should be limited to manipulate only the open documents and automate editing functions.
OpenOffice.org security concerns Posted Aug 17, 2006 9:52 UTC (Thu) by nix (subscriber, #2304) [Link] Emacs disagrees with you. Evaluation of untrusted Lisp in local-variable sections of files has been allowed by Emacs for decades: it just *shows you what the code is that it's going to run* when it asks you to run it. It's generally pretty obvious then if that's malicious.
(Of course, word-processor documents can contain whole libraries, too much code to show the user: perhaps *that* is the problem.)
OpenOffice.org security concerns Posted Aug 17, 2006 10:09 UTC (Thu) by tzafrir (subscriber, #11501) [Link] emacs will not automatically evaluate any from any document.
I admit I don't know emacs, but I know of a similar feature in vim: it is limited to a rather harmless set of commands that could not allow you to run arbitrary code.
OpenOffice.org security concerns Posted Aug 18, 2006 11:46 UTC (Fri) by nix (subscriber, #2304) [Link] So you don't know Emacs but you're willing to pontificate on what it can and cannot do?Have a look at this; search for enable-local-eval. This is a feature of ancient vintage in both Emacs and XEmacs.
OpenOffice.org security concerns Posted Jun 14, 2007 3:31 UTC (Thu) by jordanb (guest, #45668) [Link] Emacs macros were a poor decision made at a time when security was more of a geek's curiosity than a million dollar matter like it is today. And the fix for them is inadequate I think. Quite honestly, I think they should not be included at all. If you want something evaluated you should do it yourself, either with a (load-file) somewhere or by executing it interactively (C-x C-e, etc).
Microsoft Office's macro decision was still made before the Internet so they have some excuse, but their "fix" was even worse than that of emacs. They didn't reduce the ability of the macros to do damage at all, they just put up that stupid warning, and because that warning gets triggered even when the macros are clearly harmless (they don't access anything outside the local file), MS Office users grow immune to them and just instinctively click through.
Given the experience that Microsoft has had, OO.org's inclusion of macros with the exact same deficiencies is downright negligent.
I agree with the OP, macros should be restricted to a clearly-defined sandbox if they're used at all. The Emacs "solution" is especially bad in the case of a office suite because showing a macro to a secretary and asking her to decide if it's dangerous or not is like asking her if there's a dirty word in a randomly selected passage written in ancient greek.
OpenOffice.org security concerns Posted Aug 17, 2006 22:22 UTC (Thu) by bronson (subscriber, #4806) [Link] it just *shows you what the code is that it's going to run* when it asks you to run it.Just think if OpenOffice did that. That's comedy. (think of the average oo user compared to the average emacs user...)
OpenOffice.org security concerns Posted Aug 18, 2006 11:43 UTC (Fri) by nix (subscriber, #2304) [Link] Yes, there is the user-comprehension barrier as well!
OpenOffice.org security concerns Posted Aug 17, 2006 12:45 UTC (Thu) by dps (subscriber, #5725) [Link] Would it be possible add "a run in sandbox" option, which allowed the macros to run but stopped them doing nefarious things that would otherwise be possible using the all powerful scripting language?
OpenOffice.org security concerns Posted Aug 17, 2006 13:34 UTC (Thu) by kfiles (subscriber, #11628) [Link] I concur with this sentiment. We should not be curtailing the power of the scripting framework and UNO API in OOo; much like perl CPAN modules and Eclipse plugins, these lead to powerful 3rd party add-ons (like the excellent PDF Export support that was available only as a "macro" while OOo 1.1.3's PDF export was very rudimentary).
However, such code should be consciously installed by the user from standalone packages, not piggybacking on any document they open.
For document macros, a simple sand-boxed subset of features (those that can be used to automate changes in the document, perform field validation, etc.) makes more sense.
If a content provider wants a user to have more powerful macros installed, they should distribute those as a separate package, one which tells the user, e.g. "This package is requesting the ability to: change your security settings; modify files on your drive; decrypt your passwords; send email using your email client."
--kirby
some more information Posted Aug 17, 2006 16:19 UTC (Thu) by jake (editor, #205) [Link] Malte Timmermann has posted some additional information in his blog:My comments on the article "In-depth analysis of the viral threats with OpenOffice.org documents" jake
OpenOffice.org security concerns Posted Aug 19, 2006 17:29 UTC (Sat) by skybrian (subscriber, #365) [Link] This isn't what word processors have traditionally done, but what they should do. Scripting in a word processor should be at least as secure as executing JavaScript in an HTML document. Browsers have raised the bar.
|
|||||||||||||