The biggest problem I see with viruses is not that they are on a system, or not that they will even destroy a system (it's bad, but you can back up). My biggest problem is the fact that they can spread. What's more of a hassle: reinstalling one rogue system or trying to shut down a thousand systems that have been compromised and are now spreading themselves across the net. So here's my proposal. --eliminating any network access for a macro or for OO while a macro is running. You can download a file as a human, but while you are doing so macros are disabled. When you run the macros, OO will not attempt access of the Internet. I'd almost go so far as to disable any Internet functionality of OO, but I don't think anybody will buy that.
Mathias Bauer wrote: > M Henri Day wrote: > > >> «... *Is it time to now introduce such measures to the OpenOffice.org Core >> to greatly reduce any future risk from scripted infections?*» >> >> Good question.... >> > > No, it's a stupid question. > > There are only four possible ways to avoid susceptibility to viruses in > documents (a fifth one is discussed at the end): > > - don't allow to put macros in documents at all > - remove all functionality from the macro language that can be misused > for spreading viruses (e.g. accessing the file system) > - never execute any macros from documents on your computer > - know about the macros you are going to execute and grant execution > permission to the ones you can trust > > Many users won't accept the first option. Jürgen Schmidt wrote a blog > > http://blogs.sun.com/GullFOSS/entry/does_program_logic_embedded_in > > about discarding the document macro functionality also for other > reasons. It's open for debate if making this drastic step is right. > > Option 2 also is not very popular. Macros are supposed to access the > file system. If they couldn't do so many useful applications wouldn't be > possible. Unfortunately also the viral nature of macro malware builds > upon the ability of macros to access the file system. It's the same > functionality that can be used for the good or for the bad. So options 2 > would mean: remove everything that can be used to spread viruses. This > option is possible (though risky) but I have my doubts about its > acceptance. > > So we have option 3 and 4 left. OOo by default uses option 4, > configuring it to switch to option 3 is only a few mouse clicks away. > IMHO option 3 is an exaggeration as OOo has means to make option 4 > secure enough for all users that are willing to invest at least a few > thoughts (e.g. macro signatures). > > This BTW is also true for other office applications. They are not more > or less secure than OOo in this regard. > > Every technical approach to solve the problem of macro security will > just replace a simple and IMHO understandable problem (user must decide > which macros she grants permission to execute) by a complex and hidden > one (user must rely on the quality of the technical means). > > This can be studied nicely with the notorious "personal firewalls" that > replace the security holes they fix(?) by their own ones that are much > harder to fix or even grasp, especially for the average user. > > Transferred to OOo this would be something like a sandbox as in Java. > Here a user will have to grant access to e.g. the file system not on a > per macro basis (as now - giving permission to execute a macro allows it > to do everything) but on a per macro statement basis where every "risky" > operation can be denied or permitted automatically or by request. The > latter would force the user to click a button in a message box before > the macro could proceed. > > The effort to implement this mechanism in OOo would be incredibly high > as this would be a complete reimplementation of the macro language and > the whole API it uses (including UNO). > > On the other hand I'm absolutely sure that most users will switch the > "sandbox" off because they don't like clicking on message boxes all the > time when a macro e.g. saves a document. Remember the complaints about > the new "User access control" in Vista? This is done for the same > reason, it servers a comparable purpose and is comparably annoying. So I > have my doubt that the incredible effort will be justified by the result. > > It's my firm believe that security by complexity doesn't work. There are > only two ways to safeguard you against negative influences from certain > features - avoid them completely or understand what you are doing and > act wisely. If understanding potential risks of a certain feature is too > hard it should perhaps indeed be removed. I don't think that this is > true for macros. But YMMV. > > Ciao, > Mathias > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
