Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Security page
| |||||||||||||
BadBunny? Only if you invite it inThere has been a lot of press, over the last several weeks, about the "BadBunny" worm, which infects OpenOffice.org (OO.o) files. Most of the buzz seems to be about the multi-platform nature of the worm, which is interesting, but the mainstream technical press seems to miss the fact that, without a number of bad user decisions, the worm would not do anything at all. There was a lot of noise about OO.o macros and security last summer, but the situation is the same as when we last reported about OO.o security: if one is going to use an office suite with a macro language, one must be careful about which macros are run. The infected file itself is a graphics document file called badbunny.odg which contains macro definitions that can be executed when the file is loaded into OO.o. If the macro is run, it does different things depending on the platform, but attempting to infect either the mIRC or XChat Internet Relay Chat (IRC) clients is the first step. If those clients are run after the infection, BadBunny will try to propagate by offering the document file to other connected users. As a secondary payload, BadBunny stores and runs a script file that tries to infect other files in the directory where the document file is stored. For reasons unknown, each operating system gets a script written in a different language: for Linux it is Perl, MacOSX is Ruby, and Windows is Javascript. BadBunny also attempts to do a "ping of death" denial of service attack against multiple anti-virus sites. The worm was first reported by the anti-virus company Sophos back in May and was described as a "proof of concept" that was emailed to their researchers. The name, BadBunny, comes from the names of various files that get installed as well as a pornographic image of a man in a bunny suit that may be displayed. More recently, anti-virus vendor Symantec has reported BadBunny "in the wild", but it is not very widespread. There are some pretty good reasons this worm has not spread widely. Users are becoming more aware of these kinds of problems and many already know to be "cautious when handling OpenOffice files from unknown sources" as Symantec suggests in their announcement. This is not, of course, an OO.o-specific problem. All files from unknown sources should be treated with care. In order to be affected by BadBunny, users will also have to enable the macros to run. As reported by Malte Timmermann, Sun's OO.o Technical Architect, the worm does not bypass the OO.o security checks and the user will be prompted before the macros are run. One can certainly imagine that there are users who will receive a file of unknown provenance, perhaps by email or over IRC, open it and run its macros, but they are, hopefully, few and far between; this is certainly not the infection vector of an attacker's dreams. Like it or not, macro languages in office suites are here to stay. They have their uses (and abuses). For the most part, users will not even consider using an office suite that does not offer a scripting language. As Timmermann puts it:
OpenOffice.org has a macro language with access to local resources.
Of course this macro language can be used for performing any kind of tasks, that's the intention of it! Users shouldn't run macros from unknown sources, same like they shouldn't run any programs or other scripts from unknown sources. It could be argued that the OO.o macro language should be simplified in ways that might help cut down the potential for abuse. It is difficult to see how that can be done when the major competitor, at least in the Windows world, has a "full featured" macro language. The balance between security and new features is always tricky, but when trying to compete against an established market leader, sometimes the features have to win. If you believe that an office suite requires a sophisticated macro language, these kinds of problems cannot be considered security holes in the program; it is doing exactly as the user instructed it to. Individuals or organizations that want to use tools with these capabilities have to be security conscious. In the end, if users are going to blindly click through any kind of warning, any reasonable level of security is impossible. This is true no matter what operating system, web browser or office suite is used. (Log in to post comments)
Why not sandbox it? Posted Jun 14, 2007 5:51 UTC (Thu) by eru (subscriber, #2753) [Link] I don't buy this idea that an office suite must have a fully virus-capable macro language to be competitive. It would not limit much the useful capabilities of the language if it operated by default in a sandbox, where it cannot access anything outside the document currently being worked on without asking the user for permission with a dialog box that makes clear the request comes from a potentially dangerous macro. Some capabilities should be forbidden totally, like starting programs, or creating or modifying executable files.By the way, a MS Office-style "security setting" of asking the user permission before running macroes in a document is totally useless. In corporations, many documents are based on templates with macroes, so you would get the silly question every time unless you turn the check off. Far better to ask permission for a possibly dangerous access, not merely starting a macro.
capabilities Posted Jun 14, 2007 6:31 UTC (Thu) by zooko (subscriber, #2589) [Link] Hopefully someday such macros will be run with capability-based access control. That would prevent the code from exercising authority that was not granted to it, as well as allowing it to exercise authority that was granted to it. A user interface such as CapDesk, Polaris, or Plash would allow the user to grant authorities *without* pop-up dialog boxes, thus improving on both the security and the ease-of-use of current access control paradigms.
BadBunny? Only if you invite it in Posted Jun 14, 2007 7:11 UTC (Thu) by beejaybee (guest, #1581) [Link] "The balance between security and new features is always tricky, but when trying to compete against an established market leader, sometimes the features have to win."
Sorry, guys, the vast majority of users of office suite software are not security minded - they undoubtedly will click through viruses if the promised "benefit" is big enough, especially when they're working on corporate systems that they're not responsible for cleaning up after malware infestation.
Put a revolver with all chambers loaded with live rounds into a typical office suite user's hand, tell them that if they point it at their head and pull the trigger they'll see a picture of Paris Hilton/Brad Pitt naked (according to sexual orientation) and most of them will happily smear their brains over the wall.
Dangerous features need to be kept out of the hands of those who are not properly trained to avoid their misuse. That accounts for well over 90% of office suite users, even those running linux.
"In the end, if users are going to blindly click through any kind of warning, any reasonable level of security is impossible. This is true no matter what operating system, web browser or office suite is used."
Indeed. It would be a huge pity if features which are not needed by a large majority of OOo users are allowed to damage the security reputation of linux. OOo is far too bloated anyway, slimming it down by removing infrequently used and dangerous features would do it no harm at all.
BadBunny? Only if you invite it in Posted Jun 14, 2007 7:51 UTC (Thu) by eru (subscriber, #2753) [Link] It is not just about security-ignorant users, but basic usability. I want to be able to read an electronic document sent to me without any risk that simply opening it will do bad things. Is this too much to ask? It is an indication of the sad, sad state of this field that the answer to that appears to be "yes".To go into another bad real-world analygy, suppose a stationery manufacturer sells paper sheets that otherwise look great, are durable etc, but have the unfortunate tendency to ignite if certain designs are drawn or printed on them. I don't think they would stay long on the market, even if the manufacturer put warnings on the packages about what not to print on them.
BadBunny? Only if you invite it in Posted Jun 14, 2007 16:38 UTC (Thu) by thoffman (subscriber, #3063) [Link] If I understand correctly from reading the article, I think you can safely read anything that anyone sends you.
Just don't click "OK!" if OO pops up a dialog box asking you if you want to run the macros in the document!
That seems very reasonable for most people.
However, I think there should be a way to easily and completely disable OO macros on a per-user basis. That way, less-experienced users (such as children) who share a computer with more experienced users could safely exchange documents with school mates, etc. without risk, while the "expert" users on the same machine could use OO macros to do the nifty automated things.
But what if one needs to run the macros? Posted Jun 14, 2007 20:20 UTC (Thu) by eru (subscriber, #2753) [Link] Just don't click "OK!" if OO pops up a dialog box asking you if you want to run the macros in the document!That seems very reasonable for most people. I think it very unsatisfactory. For better or worse, the macros might be essential for fully getting the contents of the document. A related example: an ex-colleague once wrote a surprisingly short PostScript macro that when run, drew the very complex-looking logo the company used at the time, by observing how it had been put together from replicating some simple elements. A very effective way to compress into about two hundred bytes something that otherwise would take several kilobytes, even in vector form. An office suite macro might do something similar, and I think this is a very reasonable use for them: formatting the contents of the document itself for presentation without mucking about with anything external to the document and the window used to display it. I would like to allow it without questions, and at the same time prevent all potentially malicious uses. It ought to be possible, provided office suite makers drop the idea that an office suite must be a complete application development environment, and go back to what 99.9% of the users really want to do with them: create and view documents.
BadBunny? Only if you invite it in Posted Jun 14, 2007 7:33 UTC (Thu) by nim-nim (subscriber, #34454) [Link] OOo has chosen to implement core functions (dictionnary download...) through macro-ified documents. So most openoffice users will be used to the macro warning popup and click through it without a thought. (Generally speaking this kind of warning is pretty useless and only there so you can tell the press it's the user fault they were infected. Kind of like securing an area by sticking a "secure zone" sign on an unlocked door)
Sun management is pretty much is denial about the whole issue but the truth is with regard to macro security OO.o is on par if not lagging behind Microsoft Office.
A secure internet-era office suite should thoroughly limit the scope of macros, make sure no default function depend on them, and use digital signature checks to vet macroified documents (esp the ones distributed with the suite)
"BadBunny" is not spreading because its malicious payload was badly coded, OO.o is badly integrated in the OS and not that used, not through any particular virtue of OpenOffice security.
Office suite security is hard Posted Jun 14, 2007 9:28 UTC (Thu) by MathFox (guest, #6104) [Link] For programmers (and I include the developers of office suite scripts in this group) it is great to have a powerful programming language with easy access to the features they may need, like local file access, network access, GUI elements, etc. This will quickly lead to Turing- and virus-complete scripting languages.
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.
With tools for macro access control (controlling which functionality macros may access depending on the type of document) one can implement a security policy. An macro on/off switch is too crude, those tools have to be more sophisticated than that; people should be able to do their work effectively.
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 toautomatically 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] 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...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.
BadBunny? Only if you invite it in Posted Jun 15, 2007 9:09 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link] I can understand the need of scripting in an application, be it office or not, but why would these scripts have to be bundled with DOCUMENTS? Why not disallow having scripts in documents, and having a separate macro file? PPL have a reason to read documents, even from untrusted sources (they're funny) but not (or very rarely) run macro's...
BadBunny? Only if you invite it in Posted Jun 15, 2007 18:03 UTC (Fri) by dps (subscriber, #5725) [Link] I dropped in a prosopal, which might actually happen, of having a "run in sandbox" option which would allow macros which do things like keep the section numbers current (or whatever) *within* a document but not mess with other documents, the fact they are in the sandbox, etc.
Most people just say yes, and ignore the consequences, so an option that gives them the upside of that without the most dangerous consequences is arguably desirable. If this option is default people might use it too...
It is also desirable to allow people to contribute better PDF support and similar things (which was initially a third-party OO.o macro, at least as far as I heard it).
Disable auto-run of macros on opening document Posted Jun 21, 2007 8:29 UTC (Thu) by Cato (subscriber, #7643) [Link] Better sandboxing etc will help, but how about simply disabling auto-run macros? It's hard to think of a real reason for these, and you can simply have a button saying 'setup' in a document that really needs this.
Then the most common macro virus vector, which is someone opening a document, would require a second action. Since most legitimate documents don't have macro buttons that would make a big difference to propagation of viruses.
BadBunny? Only if you invite it in Posted Jun 21, 2007 19:55 UTC (Thu) by TehNamless (guest, #45584) [Link] It's also worth noting that Tectonic stated the situation the best: "On MacOS X and Linux platforms the virus also relies on the user executing either the Ruby scripts or XChat scripts, which most security-conscious users will not do. On Windows the automatically executing Javascript file may be more of a threat."
I myself have macros disabled for this sort of thing, though I also never just on a whim download attachments.
|
|||||||||||||