www.cs.berkeley.edu/~hilfingr/security.txt
A summary of comments on the subject of the Love Bug virus and related issues, starting with a flame from yours truly. Basically, their commentary implied (intentionally or not) that viral attacks of this nature are unavoidable, and when they (inevitably) occur, it requires active efforts on the part of the virus-scanning industry to produce countermeasures and users must be ever-vigilant to make use of the latest countermeasures as soon as they are available, and there will always be a window (hopefully narrow) during which the attacks succeed. As far as I can see, the truth of the matter is that (1') viral attacks of this nature are in principle entirely avoidable (even if one insists on having executable attachments), (2') their avoidance should not require ongoing active efforts, but (3') their avoidance DOES require some care and re-design on the part of software vendors (most notably Microsoft). As long as the public continues to believe 1-3, there will not be the pressure to accomplish 1'-3', so programs such as the one I cited are in fact detrimental to network security. I reluctantly contemplate getting publicly into the fray. First, though, I solicit your advice and comments on how most effectively to proceed. Although my remarks apply to a range of different applications, I was referring specfically to the content of the article in question: e-mail attachments. There is, of course, an obvious existence proof: I am NEVER infected by these viruses and never will be since I don't EVER look at (potentially) executable attachments except under duress and when I am very sure of their provenance. Personally, I doubt that the value added of executable attachments outweighs the risks. But let's, for the sake of argument, assume that there is some substantial value to them. Under the assumption that such attachments are valuable, there is nothing in principle that requires that, once executing, they must have unlimited access to one's system. This brings us to Joe's point: Joe Hellerstein writes: > I'm not sure I disagree with the experts. Until you show me a complete, > usable desktop computing system that's formally proven to be safe on all > inputs, I would concur with their analysis. If you don't analyze behavior > on all inputs in all states, you can't prove anything about opportunities > for exploitation. Now you can jump up and down that people > don't use well-known techniques to do that, but the spirit of their > comments is still mathematically correct. What you are saying is that because we are human, there will be bugs -- errors -- in our system security software. They were implying that successful infection by a virus is NOT the result of an error in our system software, but that our system software by its nature must inherently allow infection by novel viruses for at least the brief period before someone takes action --in effect that not even God could write a (usable) system that would keep out e-mail viruses. Remember the nature of the security systems these guys are advocating -- mutations of a virus performing a particular attack can get through. In contrast, the nature of errors in traditional OS security (as addressed, say, by security patches from Sun) is that when the error is patched, an infinite set of related attacks, regardless of mutational disguise, are forever prevented. That's what I meant by my remark concerning the pernicious nature of the biological metaphor at the retreat: we don't get infected because there are errors in our makeup, we get sick because given the design of our immune systems, we MUST be subject to attack by new (or modified) organisms. In contrast, OS's get "sick" because of buffer overruns, failures to encrypt, failures to evaluate things in the proper protection domain, and other (correctable) ERRORS. Even if we never reach perfection, we CAN get closer to it. These experts I am railing against, by contrast, imply that it is impossible EVER to get more secure. Granted, I don't know if they've actually thought about the implications of what they've said, or whether they'd change their tune when faced with my objections, but that's irrelevant to the fact that they have grievously misinformed the public. By the way, as one who dealt with his first security issue almost 30 years ago, I am not insensitive to how difficult the problem can be. In particular, I think that denial-of-service attacks are particularly sticky (although in the most recent example, the real issue was that there were systems that could be broken into to provide bases for attack). Nevertheless, in contrast to these experts, I know that the situation can be radically improved, and I believe it therefore irresponsible to suggest to the public that they might just as well shrug and accept the inevitable. These programs don't really need to be able to perform completely arbitrary operations without a user's knowledge, consent, or permission. With proper design, they could allow only certain operations (or access only to certain files) without explicit permission, and require "informed consent" for anything exotic. The burden, it seems to me, is on others to give me specific examples of what kinds of potentially dangerous operations really have to be allowed without fetter; I suspect that a careful examination will show that there aren't any such operations. Consider even the question of executing arbitrary shareware. Now in one sense there isn't much of a problem here, since a user presumably understands (in contrast to someone opening a Word document) that he is about to execute an arbitrary piece of code that can do anything, and so he shouldn't be surprised at anything that happens. However, with modern operating systems (even not-so-modern ones), the careful user could set up a special account for trying out shareware -- one with a quota and perhaps with limited net access, for example. Such "sandbox account" could be made to implement rather elaborate security policies. Of course, such treatment would not work for a utility program, but at least it is the user's decision -- as informed as he wants it to be --whether to use the utility. My point is that if relatively straightforward techniques like this can limit the damage done by rogue shareware, we ought to be able to do a really good job with Word documents. Poorly designed security is onerous, and apt to be circumvented, but well-designed security measures can be pretty convenient. I use ssh, for example, which allows very convenient access between machines. To make the security-is-too-much-trouble argument properly, one would have to produce examples of important classes of functionality that FUNDAMENTALLY require burdensome security measures to run safely. It's not enough even that they NOW require such measures, since I readily acknowledge that there is work to be done. I have yet to see a single example of an important functionality with insurmountable, INHERENT security problems. I wrote: >> Nevertheless, in contrast to these experts, I know that the >> situation can be radically improved, and I believe it therefore >> irresponsible to suggest to the public that they might just as well >> shrug and accept the inevitable. In response to which, Joe Hellerstein wrote: >Might this be the crux of your irritation? I >suppose your analogy in virus-land here would be to convene a group of family >planning "experts" to conclude that "AIDS happens", it's part of planetary >evolution that people will die from sex and drug use, and the hell with condoms >and clean needles. I agree that a little bit of >"safe computing" religion from our friends at the OS companies would go a long >way. Yes, this is the crux of my ire (it is stronger than irritation). Even here, though, beware of biological metaphor: in contrast to the situation with human sex, my point is that it is entirely reasonable to expect "automatic condoms" from vendors, so that users know when they do unsafe things and those unsafe things are pretty rare. The macro > facilities in Word and Excel are useful to some users, and because of the > way the applications are used, macros should travel with the under...
|
http://csua.com/feed/