Please create an account to participate in the Slashdot moderation system


Forgot your password?

First OpenOffice Virus, Not In the Wild 169

NZheretic writes "According to APCmag, the first cross-platform 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 developer Malte Timmermann's claims to the contrary, this kind of embedded scripting attack represents a real threat to users. Back in June 2000 when Sun first announced the open sourcing of, 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 Core to greatly reduce any future risk from scripted infections?"
This discussion has been archived. No new comments can be posted.

First OpenOffice Virus, Not In the Wild

Comments Filter:
  • The real solution (Score:5, Insightful)

    by Rix ( 54095 ) on Tuesday May 22, 2007 @01:49PM (#19224315)
    Is to stop enabling scripting by default in software that has no real need of scripting. Hasn't even Microsoft learnt this by now?
    • Re:The real solution (Score:4, Informative)

      by saibot834 ( 1061528 ) on Tuesday May 22, 2007 @01:55PM (#19224427)
      The real solution is to be careful wherever you can. Don't open email attachments of an unknown sender. Don't visit untrustworthy websites. Caution is still the best weapon against viruses.
      • by needacoolnickname ( 716083 ) on Tuesday May 22, 2007 @02:00PM (#19224523)
        What is an untrustworthy website?
        • by u-bend ( 1095729 ) on Tuesday May 22, 2007 @02:05PM (#19224613) Homepage Journal
          I dunno, doesn't call after the first date, doesn't stick up for you in a debate, cheats on you, and lies about it.
        • I should have put a bit more thought into that.

          I read this all the time. Don't go to untrustworthy websites.

          What should one do? Should they run a whois on every site before going to it? Should they then run a background check on the site owner and the technical contact, if it's not bogus or private? What if it is? Then what does a person do?

          People who go to warez sites or any movie/music download site they can find off a search engine deserve what befalls their computer - because one has to take risk f
        • Re: (Score:2, Funny)

          by Anonymous Coward
          A untrustworthy website is a website that
          - has content linked in (THAT would open a whole can of trust-this-trust-that now would it!)
          - has bugs in web, app or db server.
          - accepts malicious content including links to content
          - you don't know if you can trust everyone with or who could get admin access to that server.

          More or less. But it cant be that hard now can it, because I've heard of people making these decisions in realtime, while they surf.
          • by morgan_greywolf ( 835522 ) * on Tuesday May 22, 2007 @02:41PM (#19225149) Homepage Journal

            A untrustworthy website is a website that
            - has content linked in (THAT would open a whole can of trust-this-trust-that now would it!)
            - has bugs in web, app or db server.
            - accepts malicious content including links to content
            - you don't know if you can trust everyone with or who could get admin access to that server.

            Hmmm...this sounds familiar.

            I think you just described Slashdot.

            -- a really old /. user who remembers ALL the bugs in slash and MySQL that plagued this site.
        • Re: (Score:3, Insightful)

          by fluffman86 ( 1006119 )
          I really like McAfee SiteAdvisor [] to help me decide. It's available as a Firefox extension and turns green if a site is not known to have any bad downloads or send unwanted emails. It's gray if unknown, and red if a site has malicious downloads or sends out a lot of emails. It's by no means an excuse for not using your brain FIRST, but it helps sometimes.
        • i don't know, but once we've gathered together a list i say we make an .untrustworthy TLD and force them all to switch-over to that
      • Re: (Score:2, Insightful)

        Don't open email attachments of an unknown sender

        Many people get viruses (appearing to come) from well known trusted sources, so this advice is wrong.

        The correct thing to say is:

        Don't open unsolicited attachments or files, ever .

        If in doubt, speak to the sender and confirm its validity.
    • by Anonymous Coward on Tuesday May 22, 2007 @01:57PM (#19224455)
      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.
    • Re: (Score:2, Interesting)

      by Normal Dan ( 1053064 )
      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.

    • by truthsearch ( 249536 ) on Tuesday May 22, 2007 @01:59PM (#19224501) Homepage Journal
      Ever work in a financial company? Some live almost entirely off of their scripted Excel spreadsheets. There is a lot of value in allowing spreadsheets to support scripting. But it's the abilities of those scripting languages that's a real problem. Just like JavaScript needs to be limited in scope within a web browser, so too should the spreadsheet scripts. Unfortunately these office suite scripts are often used for things like disk access to import data.
      • Those that do can enable scripting. There's no reason to expose the vast majority who will never, ever, use that functionality to the risk. Which is why I said "disable by default" and not "rip it out and burn it".

        You are correct that vulnerable functionality should be in a protected wrapper. However, this will simply reduce, not eliminate shenanigans. Clever monkeys will still find a way.
        • by jimicus ( 737525 ) on Tuesday May 22, 2007 @04:57PM (#19227517)
          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.
      • Re: (Score:3, Insightful)

        by radarsat1 ( 786772 )

        Unfortunately these office suite scripts are often used for things like disk access to import data.

        And that, of course, is almost directly related to the fact that the MS file formats are closed. With an open format like ODF, scripts for importing data aren't critical, since it's quite easy instead for a program to export it in the proper format, or to write an external script or program to transform data into ODF format. After all, it's XML.

        Unfortunately MS has trained industry to rely on scripting to

        • by EvilSS ( 557649 )
          since it's quite easy instead for a program to export it in the proper format

          This is also the case with MS Office. Microsoft provides COM interfaces to the office products that can be used to generate documents. I do this all the time with Excel. It is actually very simple to use and well documented.
      • All or nothing script/macro access where your options are confined to on/off/ask are such an obvious problem I'm amazed that they're not taken more seriously.

        I don't get why anyone (with the users interests at heart) would add office scripting functionality without adding some form of permissions. Maybe back in the days before networking it was practical because most files were created on the computer itself or came on a trusted disk.

        It's not even an option to inspect macros on Office before opening the fil
    • I never really understood the need for scripting in an office application myself. I certainly think it causes more problems then it solves. And not just in the security aspects. It seems to me that the only things that result from scripting is security holes, and tying the user to the word processor, ala, we can't use OpenOffice, because we've programmed our entire business into MS Word macros, making it impossible to switch. Also, when scripting is provided, it should be sandboxed to ensure that nothing
    • OOo's problem IMHO is that it's an old program suite masquerading as new material. The backwards compatibility, which is necessary to its continued growth, is its albatross.

      I am a developer, but the caveot is I don't know jack about the code and its current iteration. I could and may be way off base, but here goes anyway.

      The only way you'll ever address it is to start. From scratch. Build the core of the program with security in mind. Converters have to pass through that core security layer. Add-ons n
    • Not enabling scripting by default is *exactly* what is implemented in The user has to explicitly allow macros to be executed before such a "virus" could do any damage or spread itself. So this "bad bunny" hardly poses any threat.
  • by packetmon ( 977047 ) on Tuesday May 22, 2007 @01:54PM (#19224411) Homepage
    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...
    • by truthsearch ( 249536 ) on Tuesday May 22, 2007 @02:02PM (#19224565) Homepage Journal
      I give it about 9 months before something ala SOBig/Blaster hits the *nix scene...

      You just conceived it? Congratulations! Do you have a name picked out?
    • How will Grandma do any damage if she don't have root access. Can you point me to a URL or email me a link that runs venomous from a mouse click.
      • Re: (Score:1, Insightful)

        by Anonymous Coward
        Thank god /usr/bin is read-only! Its sentimental value is irreplaceable. Grandma can, of course, get /home back off the install disks. Hey, wait.
    • by MobyDisk ( 75490 )
      How is this related to this discussion? The post links to a shell script that must be run as administrator. Not something that can be embedded into an OpenOffice Javas plug-in running as non-admin.
    • by jimicus ( 737525 )
      FWIW, I agree that Unix, like any desktop computer system, is only as secure as the user who's sat in front of it.

      IMO, all these people saying "Unix can't suffer from viruses therefore it's secure!" are living in a fools paradise where they don't appear to have realised that the "executable file infector which spreads when the infected file is executed"-type virus is all but dead, and most things described as viruses today would be more accurately described as trojans.

      I don't think anything much will change
  • Virus Name (Score:3, Funny)

    by T-Bone-T ( 1048702 ) on Tuesday May 22, 2007 @01:55PM (#19224421)
    How does one come up with a name like "SB/Badbunny-A"? Virus names never make sense to me.
    • Re: (Score:2, Informative)

      by Anonymous Coward

      "The worm attempts to download and display an indecent JPEG image of a man wearing a bunny suit performing a sexual act in woodland."
  • by Anonymous Coward on Tuesday May 22, 2007 @01:55PM (#19224423)
    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.
    • Documents shouldn't run scripts unless explicitly authorized to do so.

      Running scripts should not be a binary issue. Scripts should always run, by default, in an appropriate security sandbox, and only get additional privileges through explicit user interaction or through some kind of trust mechanism.

      Programs that load scripts from external sources should not be gaping security holes, just because I trust a program doesn't mean that my only choices with a script should be trust it as much as I trust the prog

      • Sounds a lot like Java. Therefore it will never fly.

        There will always be a vendor like MS to make everything so much easier for us, without thinking about the consequences. It will happen on Linux too. Some would argue it already is (just compare most Linux distros to OpenBSD for example), just not nearly as bad as on the Windows platform.

        Featuritis is an illness that is cross platform I'm afraid. Many small and efficient projects seem to be doomed to become bloatware, once they've become popular.
        • Sounds a lot like Java. Therefore it will never fly.

          There will always be a vendor like MS to make everything so much easier for us, without thinking about the consequences. It will happen on Linux too.

          Really, in this particular case, its an application issue not an OS issue, and its already happened with regard to plenty of Linux apps that support scripting.

          Having a fairly secure OS doesn't you limited good if applications that run with reasonably broad permissions, for good reason, themselves serve as pla
    • Documents shouldn't run scripts unless explicitly authorized to do so. That goes for word processors, spreadsheets, PDF readers, email clients and web browsers.

      ....except, of course, that PDFs are Turing-complete scripts that tend to make pretty pictures.

  • 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?
  • by RobertM1968 ( 951074 ) on Tuesday May 22, 2007 @01:58PM (#19224467) Homepage Journal

    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!!!

    • My previous posts have heaped enough criticism on OOo, so I won't do that here, no matter how good it might feel to vent my frustration.

      What I want to do is figure out why OpenOffice is such a steaming pile of crap. Why would someone want such a slow, bloated program? Who decided it would be a good idea to turn on scripting by default? When are they going to make a decent user interface?[1] Well, I think I've figured out a few places where OOo is not like other open source software. Perhaps we could le
  • by brunes69 ( 86786 ) <slashdot&keirstead,org> on Tuesday May 22, 2007 @01:58PM (#19224473) Homepage
    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 (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" than runs "rm -Rf ~/", is that a virus too?

    • If I email you a shell script named "Click" than runs "rm -Rf ~/", is that a virus too?
      If you listened to some of the people here, you would begin to think so.
    • Re: (Score:3, Informative)

      by mcrbids ( 148650 )
      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.

      Why not? Ostensibly, OO will run as user YOU, and YOU have access to your Tbird address book, and so would OO. Unless you're running SE Linux like a bat out of hell (most people don't) or have chroot or suid set up. Most *nix users however, don't have this kind of set up.

      • by brunes69 ( 86786 )
        My point is it's Linux, there is no way for the virii writer to deduce what program I am using to manage my addresses. It could be thunderbird, it could be KABC, etc etc. He will either have to write a ton of code to catch all those cases, or not bother. Oh an even if he does OO will not let him execute a program to send mail.
        • Re: (Score:1, Insightful)

          whereis insert_mailapp_here?

          because we all uninstall everything we don't use right? you fail to see that they can be written to use other apps, this just happens to use mirc or xchat.

          never underestimate a determined thief.
        • If your victim is running Debian or one of its children, there are always alternatives. []
        • If the virus were to target a specific distro, like Ubuntu, then it could make assumptions. It could even check for both Evolution and Thunderbird in the OO user's home DIR and use either or if present.

          If the virus creator were especially vigilant then they could test for all sorts of installed applications with existing and exploitable/profitable data under ~/
      • by joe 155 ( 937621 )
        "Unless you're running SE Linux like a bat out of hell"

        You say it like there is something wrong with running SE Linux or that it will make your experience of Linux worse. I run it and I've only ever had one problem which we managed to diagnose and file a bugzilla report which got it fixed within 4 days... not bad really. I can honestly recommend it for everyone.

        I do see the problem though which you mention, namely that you can still do enough damage whilst running as user - especially because it cou
    • by mibus ( 26291 )
      Does anything stop this from saving a new ~/.bashrc with "rm -rf ~/*" in it?
  • by rs232 ( 849320 ) on Tuesday May 22, 2007 @01:59PM (#19224495)
    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
    • Re: (Score:3, Insightful)

      by geekoid ( 135745 )
      I don't know of any wide distro that doesn't have Perl or xchat.
      Getting write and execute permissions is a concern. Because they wider the Linux audience, the more people will want to double click on an attachment to see the 'dancing ponies' or whatever.

      Sad, but true.

      • Actually, xchat isn't on my Slackware distribution for what it's worth.

        Not that I use ICQ/Other much anyway, as it tends to be a security hole.

        And when I do use it, it's chrooted to a protected account anyway.

        Feel free to infect my chrooted jail all you want. Really :)

        That's the biggest issue that I think a lot of Linux advocates are saying is the big difference between Windows and Linux.

        Both don't protect against absolute incompetence, but if you're going to be boned, get boned on Linux. Most people who
    • "any self respecting Linux user"

      Have you ever taken a look at who you are talking about?
  • Why must Sun (Score:4, Insightful)

    by gillbates ( 106458 ) on Tuesday May 22, 2007 @02:02PM (#19224545) Homepage Journal

    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.

    • by geekoid ( 135745 )
      Did you read what needs to happen to run this virus?

    • Users are impressed by features. Reviewers are impressed by features. The review articles are filled with tables tabulating what product has what feature. So people acquire stuff that has vast numbers of features that they will never use. Features sell. Just look at consumer products.

      More features = more attack surface = lower security.

      Running downloaded (generally untrusted) code = rich extensibility = bad security. After all, the code writer is doing what they want, not necesarily what you want.


    • by guruevi ( 827432 )
      To say it with Gates' words: it's not a vulnerability, it's a feature.

      If you RTFA it's not a self-propagating virus that doesn't require interaction or stupidity by the user. But then again, the general populus is stupid and clicks yes for everything.

      It's a 'script' that does something bad, not a virus. It's not even close to a macro 'virus'. You could call it a trojan by a far call.
    • by bkr1_2k ( 237627 )
      Not to be thick, but since when has security been a selling point for OO? I've heard a lot of things about OO over the years, but not once have I heard, or spoken of security as a selling point. Have I (and all my friends) been out of the loop somehow?

      Most people don't consider security when they're thinking of writing a document. They think about how they format their documents, how people will read their documents, and how much that will cost them. Other than that, I think most people don't give a dam
    • ...copy Microsoft's mistakes?

      Well, they DIDN'T.

      The default behaviour of with a document containing macros is that the user has to explicitly allow them to run.

  • OpenOffice really does violate Microsoft patents. /ducks
  • ....Just when you thought it safe to go back to the wordprocessor....

    (Cue screen of XRoach for no obvious reason)

    ....from the darkest of nightmares comes a haunting tale of OpenOffice viruses.....

    (Images from DOOM, for the oblig. explosions and gratuitous violence) innocent who went too far....

    (Typing on an XChat console, the first related scene so far but still stupid)

    ....amongst the ruins of a once-great empire....

    (Scene shifts to Sun Microsystems and then to the OpenOffice group - vaguely related, sort of)

    ....and the darkest passions of a genius....

    (Switch to any old virus research lab, nobody can tell them apart)

    (Switch to a movie certificate for Open Virus, the Movie, rated C++)

  • Trust (Score:4, Interesting)

    by Carcass666 ( 539381 ) on Tuesday May 22, 2007 @02:54PM (#19225361)

    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.

    • Some of this is done in MS Office 2007 - new-style Office documents with macros embedded are indicated with a .docm, .xlsm, .pptm type extension (as opposed to .docx, .xlsx, .pptx). What's more, Office refuses to open the document if it's renamed to the non-macro containing extension, giving a "file corrupted" error. Even then, Office is set to refuse to run all macros that aren't "trusted" by default, so it gives an information bar saying that macros are disabled and giving you a chance to enable depending
  • 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.
  • virusscanner bloat (Score:3, Insightful)

    by pe1chl ( 90186 ) on Tuesday May 22, 2007 @04:50PM (#19227359)
    was emailed directly to Sophos from the virus developers ... who dutyfully included it in their signature database, so it will be looked for in millions of computers even though it is not in the wild.

    meanwhile, our computers get slower and slower. virusscanners eat up lots of resources and become ever slower. I recently noticed clamav takes 13 seconds to scan an infected .scr file of 16kb before deciding that it is safe (because it not yet had the signature).

    wouldn't it be time that antivirus companies slim down the signature lists a bit. of course it is cute to boast a "number of signatures" above 100.000, but who is really getting benefit from the scanning of all those hypothetical viruses?
  • using restricted-mode execution by default and access by signed digital certificates.

    Yeah, similarly on how signed extensions would make firefox safer??

    I have yet to se 1 (ONE) signed firefox extension...
  • The way to be safe(r) from scripts is to require OO.o to check the signature of any script against the sigs of all scripts in a distributed repository. All the scripts' sources are open. People can test them out, and report them to the repo's (distributed) security team. If OO.o doesn't find the sig of a script in the repo, OO.o can submit the script to the repo and warn the user their script is untested before executing it.

    This kind of architecture is one way that Debian (and derivatives) is protected by A

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982