First OpenOffice Virus, Not In the Wild

NZheretic writes "According to APCmag, the first cross-platform OpenOffice.org virus — 'SB/Badbunny-A' — was emailed directly to Sophos from the virus developers. The proof-of-concept virus affects Windows, Mac OS X, and Linux systems and uses different methods on each. It has not yet been seen in the wild. Despite Sun's OpenOffice.org developer Malte Timmermann's claims to the contrary, this kind of embedded scripting attack represents a real threat to OpenOffice.org users. Back in June 2000 when Sun first announced the open sourcing of OpenOffice.org, the twelfth email to the open discussion list put forward a two-part solution for providing OpenOffice users with Safe(r) Scripting using restricted-mode execution by default and access by signed digital certificates. In October 2000 the issue of treating security as an 'add-on' feature rather than as a 'system property' was again raised. Is it time to now introduce such measures to the OpenOffice.org Core to greatly reduce any future risk from scripted infections?"

The backdoor from hell

[packetmon]

So how long should we count down to until someone embeds the backdoor from hell [infiltrated.net] in not only Linux, but Solaris [security-protocols.com], then the BSD's... As an FYI... I've got a functional backdoor-worm for Free and Open ... Just makes no sense to even post it. Many don't even get what I mean when I state "there is a world of pain coming your way if you do that [infiltrated.net]" ... Mark the calendars, I give it about 9 months before something ala SOBig/Blaster hits the *nix scene...

Why not use another alternative?

[El Icaro]

I realize this is just my case, but I only need Linux and I use Koffice for my office needs. I lack enough technical knowledge to prove it but it seems faster and lighter than OpenOffice. Are there any other free (either type) office packages on Windows? How about Mac?

Re:The real solution

[Normal Dan]

The trouble with this solution is customers want things to just work. They do not want to have to mess with security settings. If all scripting is disabled, people will get frustrated and blame the program instead of the file, then use a different program.

I have seen this happen with web pages and FireFox. People complain that FireFox does not work with several web pages, when in reality, those web pages (which are tailored for IE) do not work with FireFox.

etc.

Trust

[Carcass666]

Scripting is a very important part of Office productivity suites. This is not going to change. But what does have to change is the notion of "I'll just toss in a macro with my document/spreadsheet". In reality, macros can get so complex, especially with Microsoft Office's ability to set up references to COM libraries, anything but the simplest macros require careful distribution.

Documents and spreadsheets should not have macros. Ever. The Office vendors need to make it a lot easier to create macro files that are distributed differently than document files. If you have to send along macros to recalc/resort a spreadsheet or something, they should go in a different file. When you open the macro file, the Office app should state which macros that are being activated, and give you the option to use them temporarily or permanently, and by default do not allow them access to the file system unless you specify otherwise, etc. Enabling/disabling macros is not enough, there needs to be levels of trust.

Certificates are good things, especially if you are a company that uses macros a lot internally. But for an individual, getting a code signing certificate by a trusted authority is cost prohibitive and difficult. The Office macro engines simply need to do a better job of limiting the exposure to macro vulnerabilities and make it easier for Joe User to distribute macros in a "responsible" manner.

You CAN NOT have a "leaky" sandbox.

[argent]

The kind of "leaky sandbox" that we're seeing here was virtually unknown in the '80s and '90s. If a macro language had any kind of ability to work outside the codument layout itself, it was either restricted to applications where it was a moot point (if the preprocessor for your compiler could run scripts... so what, the code in between the preprocessor directives could do anything) or it was a mistake and the abaility was removed when it was discovered (as in the case of ghostscript).

In 1997 Microsoft introduced Active Desktp, which included a deliberately "leaky" sandbox... controls and scripts that were on pages considered "trusted" could get anything up to full local-user access. In addition, Microsoft responded to Word macro viruses NOT by restricting the scripting language in Word (as expected) but by putting in checks to disable the ability to even examine macros if a document seemed suspicious. And they still haven't learned their lesson.

What's worse, this practise is spreading. While nobody has extended this model nearly as far as Microsoft, Firefox XPI installation involves having a web page request installation of unrestricted macros, and Apple lets you run software installers automatically if the user has left "Open safe files after downloading" enabled.

This kind of thing HAS to stop.

If you design an "inherently safe" scripting language, on ethat does not provide any hooks from *within* the documentto even requests the ability to modify mor ethan the document itself, then any security holes are bugs and can be patched without inconveniencing users. More powerful tools should always be run or installed from outside the document, explicitly under user control, and preferably from a version of the application that doesn't include a mechanism to access remote documents and is not ever invoked from a browser or mail program... or any other application intended to work with untrusted documents.

This design, which used to be taken for granted (the idea of an email worm that could even potentially be run by just viewing an email message used to be a *joke*... everyone *knew* that nobody would be stupid enough to make the Good Times virus real) is not "clumsy" or "inconvenient". It's more convenient than the environment we're in now where applications are perpetually bringing up "Hey! I'm about to do someting stupid! You wanna let me?" dialogs that people reflexively swear at as they approve the stupid action.

We need to turn this around, folks. Bring back the sandbox, don't even include the commands to write files in the sandboxed versions of the macro interpreter, and stop turning the Internet into some kind of bad science fiction movie where the earthlings infect the alien computer from a Powerbook.