Slashdot Mirror
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?"
Is to stop enabling scripting by default in software that has no real need of scripting. Hasn't even Microsoft learnt this by now?
So how long should we count down to until someone embeds the backdoor from hell in not only Linux, but Solaris, 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" ... Mark the calendars, I give it about 9 months before something ala SOBig/Blaster hits the *nix scene...
Infiltrated dot Net
How does one come up with a name like "SB/Badbunny-A"? Virus names never make sense to me.
Documents shouldn't run scripts unless explicitly authorized to do so. That goes for word processors, spreadsheets, PDF readers, email clients and web browsers. The problem is that the world is full of dickheads who needlessly distribute documents that require executing script, so users end up clicking yes every time.
Imagine how few viruses and trojans there would be if requiring script was the exception rather than an unfortunate rule.
Oh well, we can all dream.
Scripting itself is a virus that spreads through programmers: once a programmer has seen scripting somewhere it doesn't belong, he feels a sudden urge to add scripting to the project he's working on.
:BEGIN HUMOR:
Well, finally OpenOffice has become a viable Office Suite, having finally added the most notable features of Office, namely script exploit capabilities. It's about time... now there is nothing keeping people from switching to OO!!!
:END HUMOR:
StarTrekPhase2 - The Five Year Mission Continues!
So I open this OO doc in Linux.... is it going to read my address book and email itself to other people? No, OO does not have access to my Thunderbird address book.
Is it going to infect other binaries in my system? No, they're only writeable by root.
Oh wait this is how it works:
"SB/BadBunny-A spreads by dropping malicious script files that affect the behavior of the popular IRC programs mIRC and X-Chat, causing them send SB/BadBunny-A to other users. These malicious script files are named badbunny.py (for XChat) and script.ini (for mIRC, overwriting the existing mIRC file) and are also detected as SB/BadBunny-A."
So.. this "virus" relies on some twisted assumption that I use XChat, to send itself to other people RUNNING XCHAT, NOT OPEN OFFICE?!?
So tell me again how this is a virus? If I email you a shell script named "Click me.sh" than runs "rm -Rf ~/", is that a virus too?
This worm or virus depending on who is saying it, requires Perl, XChat and write and executable access to be able to run. None of which applies to any self respecting Linux users computer. Yet another bogus Linux 'virus' article. Must be a slow day for real news.
"They are attacking the vulnerability of people's brains ", Graham Cluley, Sophos
davecb5620@gmail.com
Copy even Microsoft's mistakes?
I mean, really. We've known about macro viruses for 20 years, and the danger of putting executable code in documents for about the same, and yet, in 2007, an open-source application, backed by a major UNIX vendor is released with this vulnerability?
Apparently many eyes do not make bugs shallow. I guess the community was asleep at the switch. Or maybe, something in the process is broken. Or maybe Sun just doesn't care.
Now, lest you think this a troll, consider: Security and virus immunity have been a big selling point for open source systems. Until now. Sun is a large player in the open source arena, and this makes everyone else - secure or not - look bad. Security was the major selling point for OO, and now that it's questionable, I'm not sure where Sun is going to go with this: they can't compete with Microsoft on features, OO is far from a universal standard (which means you're going to be plagued with interoperability issues), and OO's last major selling point is that it is free as in beer.
The society for a thought-free internet welcomes you.
(Cue screen of XRoach for no obvious reason)
(Images from DOOM, for the oblig. explosions and gratuitous violence)
(Typing on an XChat console, the first related scene so far but still stupid)
(Scene shifts to Sun Microsystems and then to the OpenOffice group - vaguely related, sort of)
(Switch to any old virus research lab, nobody can tell them apart)
(Switch to a movie certificate for Open Virus, the Movie, rated C++)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
In any company, there's a whole bunch of departments other than IT.
Those departments don't always fancy calling the IT department when they have an IT requirement - particularly if it doesn't seem that complicated. There is always someone in the department who knows their way around Excel (and possibly Access) better than any of their colleagues. So they cobble something together in some 'orrible mess of VB macros linking who knows what files, referential integrity or scalable design be damned.
Were you to audit any sizeable business for spreadsheets made somehow interactive with scripts and badly designed databases thrown together in Access, I guarantee you'd be amazed and disturbed in equal measure. And you really don't want to start trying to figure out which ones have somehow become critical to the business.
This has been going on for years. Try taking that functionality away today, you might as well suggest replacing their computers with slide rules.