Subject: RISKS DIGEST 16.91 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 14 March 1995 Volume 16 : Issue 91 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See previous issue for further information, disclaimers, etc. ***** Contents: Re: PGP Moose -- Not just the headers! (William Oswald) Re: Automatic return fire (Joseph Chew) Scientology Blackmail Risk (John V. Vilkaitis) Viral morality (Rob Slade) [LONG] ---------------------------------------------------------------------- Date: Tue, 14 Mar 95 18:06:18 EST From: William Oswald Subject: Re: PGP Moose -- Not just the headers! (Leichter, RISKS-16.90) >... beware! Any "From:" lines you include are likely Moosebait! I recently sent to the mailing list folk_music@nysernet.org this followup to a thread in which readers were contributing names to a list of recommended female blues guitarists: >Please add Cindy Cashdollar -- a fantastic blues Dobro player. >I saw her backing up Leon Redbone a few years ago in Phila. at one >of the Penn's Landing concerts, and I would sure like to hear more. I was surprised to receive the following bounce: >Subject: Error Condition Re: Re: Female blues guitarists summary >X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas >X-Comment: Folk Music Mailing List >We are sorry, but this system sensed the following request which may have >been inadvertently sent to this list: >PLEASE ADD >If your posting was intentional, please accept our apologies and resend your >mail message, making sure you do not include anything that may look like a >request in the first line of the body of the actual message. If this was >indeed a request please resend it to listserver@nysernet.org William Oswald -- siwgo01@sip.unisys.com ------------------------------ Date: Tue, 14 Mar 1995 14:41:15 -0800 From: JTCHEW@lbl.gov (Ad absurdum per aspera) Subject: Re: Automatic return fire (RISKS-16.90) Well... I trust that this is simply a case of a missing thought that seemed obvious to the speaker, namely, that the shooter would be subject to return fire by the human, if there were a clean shot and the situation otherwise justified returning fire. The description is interesting, though. Makes it sound as though some kind of active millimeter-wave radar or sonar-like device were in use, as opposed to passive triangulation of the sound of gunfire. This presents intriguing technical problems. The bullets of common small arms are roughly... oh, for these back of the envelope purposes let's say they're the size of a pencil eraser. They move anywhere from about 800 feet per second (the .45 automatic pistol) to as much as 3000+ fps (the AR-15). They are almost always, but not neces- sarily, made of metal. Now, consider that they are fired at ranges from 7 yards (which the conventional wisdom says is the maximum range of most civilian shootings) to contact. An exception might be a drive-by shooting at several tens of yards, or an urban sniper situation at perhaps a couple of hundred yards. We can probably disregard these because of transmitted power and, in the case of a sonar, timing considerations. So this James Bond gizmo might have as little as .007 seconds in which to do the job. In an urban environment it also has to gate out echoes. And unless it's a slick Doppler job, it has to get two readings. Finally, unless it also catches the sound of the gunshot, it *still* doesn't give you the range, just an idea of where to look, based on what you hope is the trajectory. Meanwhile, in case solving realtime problems in three dimensions isn't fun enough, the shooter might well have moved and/or hidden his weapon. This could well be quite a tactical asset to a police team. Maybe even an individual officer, in giving him a clue as to where to look. It certainly isn't a cure-all, and, especially in the case of a lone officer, it's easy to imagine RISKS associated with getting into a "heads-down mode" to run a technological crutch and forgetting the tactical situation. Joe ------------------------------ Date: Tue, 14 Mar 1995 14:32:39 -0800 (PST) From: javilk@netcom.com (Javilk) Subject: Scientology Blackmail Risk If, as was mentioned in the prior edition, the Finish police handed all the anonymous ID database to the Scientologists, many of the people who have used the anonymizing service may RISK exposure to some form of blackmail attempts. One has only to look at some of the articles posted in the Scientology forum on the Usenet to see what they are often accused of. A few thoughts from a course I once attended at IBM on industrial espionage: The typical means of gaining control used by some intelligence services, (including private ones,) and often cults, is to make a series of minor but unethical or illegal requests which, once filled, would place the victim greater and greater conflict with their employers, the law, and/or society if their deeds were to be made public. The goal is to deny the victim access to legal and societal services. (And in the case of cults, outside moral support.) Eventually, the victim has no choice but to comply with even the most hienious of operations, or risk long term incarceration, or worse. One way to avoid this scenario, is to call the would-be blackmailer's bluff and say "No" at the outset. A better way, would be to seek out and cooperate with an appropriate company security or law enforcement agency, such as the FBI, so as to help them turn the blackmail operation into a sting. The would-be victim is usually given immunity from prosecution. In most cases, the typical minor transgressions spoken of via an anonymizing service user would be laughed at by the police; but the concept of blackmail on an organized scale should be taken quite seriously by an organization such as the FBI. One should also note, that if the FBI, CIA, etc. are not watching the anonymizing services, they are sadly in remiss of their duties. It does not take much to crack such a service! Thus one may suspect that voluntary cooperation at the outset might be to one's benefit in most cases; and in some cases, being blackmailed by a more nefarious organization may actually turn out to be a relatively opportune event. If the Scientologists begin to fear that many of their potential victims would turn to the FBI, they may become more reluctant to pursue potential victims. Perhaps we should push this concept a bit on the net and elsewhere. John V. Vilkaitis, Senior Consultant, Software General Corp. javilk@netcom.com ------------------------------ Date: Tue, 14 Mar 1995 18:25:21 EST From: "Rob Slade, Social Convener to the Net" Subject: Viral morality VIRETHIC Viral Morality: A Call for Discussion "Computer ethics" has been an ongoing study in the technical world. On the one hand is the study of the ethical, moral, or proper use of computers. On the other, is the study of computer crime and vandalism. Lately, I have noted a rather desperate interest in courses or training in computer ethics, as well as an increase in the frequency and depth of discussions regarding the ethics of virus writing. I would like to address this latter topic, specifically. One problem with current discussions and literature regarding the ethics of virus writing and distribution is the lack of dialogue between two opposing camps. This paper is not intended to present any final answer, nor to add to the literature in the field, but to open the field for comment. My purpose in writing this is to provide an initial overview and to elicit feedback from any and all concerned with the topic. For those of traditional moral stance, the current situation is discouraging. Peter Denning's "Computers Under Attack" (cf. BKDENING.RVW) has a very thorough survey of the field, but it provides little in the way of answers or hope. Deborah Johnson's work "Computer Ethics" (cf. BKCMPETH.RVW) is pre-eminent in the field, but serves only to clarify the problem. Sarah Gordon's interviews with computer students show responses typical of almost all such studies. The base attitude appears to be, "If I find it interesting, and I can do it, why do you say I shouldn't?" The proponents of security-breaking activities often question the traditional ethical position by asking, "Where's the harm?" This query is directly relevant to discussions of the morality of virus writing. I should begin by defining two generally opposed groups in this area. First is the "antivirus", or "AV", research community. Many, though not all, of the members of this group would be involved in producing antiviral software. All would study viral programs with a view to eliminating viral programs in the normal computing environment. They take a rather paranoid, and almost obsessive, position with regard to the sharing and distribution of viral code. (They would rejoin this last by pointing out that it isn't paranoia if someone is *really* out to get you.) The AV community is not really opposed to the writing of viral programs. It is seen as a trivial, and therefore pointless, exercise; but not necessarily evil, in itself. The communication of viral program code is also a normal professional and academic activity, as long as it is limited, done for a stated purpose, and the recipients are known. It is the unregulated exchange of virus code and source, providing open access to anyone with a computer and a modem, that is upsetting. The opposing group is therefore described as the virus exchange community, or "vx" for short. (This designation was first used by Sarah Gordon.) For the purposes of this paper, therefore, references to "virus writing", "virus exchange" or "vx" will mean the uncontrolled or unregulated exchange or provision of access to virus source and object code. (This does not necessarily mean deliberate distribution of infected programs by such means as infecting a legitimate program and then posting it, without warning, to a bulletin board system. "Trojanizing" of normal software or malicious invasion of systems is certainly happening in some areas, but it is not needed in the current computing situation. While there is debate over the relative contribution of "natural spread" and virus exchange to the current virus problem, it is known that code made available only as openly published material does eventually infect machines in the normal computing environment. The term vx does not, therefore, require any imputation of sinister motives or hidden activity for the purposes of this discussion.) There are some grey areas between these two poles. Some people have both written antiviral software *and* contributed to viral spread. Given, however, that one could expect a continuum of opinion, those in the middle are remarkably few. Either you are for virus exchange, or against it. One other, separate, group should be noted. Viral programs are often cited as an example of "artificial life", and the research community in that field, both professional and amateur, have a legitimate interest in viral programming. Work in the a-life field, however, does not justify unregulated code and source exchange. For one thing, current viral programs "in the wild" (those which are to be found in normal home and business computers, as opposed to those which exist only in a research or laboratory environment) have only the most tenuous claim to artificial life. Common viral programs are simplistic snippets of code without anything like the complexity of the simplest known natural life forms. In addition, those who really do work in the artificial life area will be well aware that it does carry possible dangers, and that research should be subject to controls similar to those imposed on biological and genetic study. The most common argument for virus-writing tends to boil down to, "You can't stop me." Many promote virus writing on the grounds of freedom of speech, a rather curious position in light of the incoherence of the arguments. (The most vocal of these tend to be Americans, who frequently cite "First Amendment Rights". This refers to the first amendment to the U.S. Constitution, which Americans tend to see as some universal law, rather than an arbitrary political document, however desirable.) Rights, though, carry with them a weight of responsibility. As is often quoted, your "right" to swing your fist ceases at the end of my nose. You have a "right" to free speech--so long as you are responsible and do not perpetrate fraud. You have a "right" to study whatever you like--so long as you are responsible enough not to carry out experiments in poison with human subjects. No PC is an island--at least, not where viral programs are concerned. Therefore, your "right" to study, write and distribute viral programs carries the responsibility to ensure that your creations do not--ever--run on machines where they are not authorized. One of the most confusing aspects of the "exchange/no exchange" debate is the concept of the "good" virus. There is nothing inherently evil in the concept of reproduction. (Dangerous, yes.) In fact, the very earliest experiment with self-reproducing programs was the Xerox Worm of Shoch and Hupp. This was designed to spawn "segments" of the central program on other machines in the network, thus bringing the power of many processors to bear on a single problem. Thus, in theory, viral programming could represent the same level of advanced technology in software that parallel processing represents in hardware. That's the theory. And it is promoted by no less eminent a researcher than Dr. Fred Cohen, who did seminal work on the security-breaking class of viral programs in a thesis, in 1984, and dissertation, in 1986. Unfortunately, the theory founders on some rather hard facts. There are three questions to ask of a new, inherently dangerous, technology. Has it a useful application? Can it fulfill that application better than current technologies? And, can the danger, either inherently, or effectively, be controlled? To date, no one has answered those three questions. While a variety of uses have been proposed for viral programs, there are none which are not effectively being done by other means. No viral programs have, indeed, been seen to be as effective as normal systems. Operating system upgrades could not guarantee universal coverage. Network management tasks could not promise reliable feedback. Automated utilities would confuse novice level users, who never run utilities anyway. The most useful function is still that proposed by Shoch and Hupp--and their programs were not, strictly speaking, viral. (Vesselin Bontchev's examination of this question is the most detailed to date, and is required reading for all who want to join the debate. His proposals, while demonstrating good ideas for safety and control, are still primarily an advanced automated distribution system. The necessity for viral functions in this regard is still unproven.) Those in the vx camp will point to two current viral programs which, they say, do have useful functions. One of these programs produces compressed executable files, thus saving disk space, while the other performs encryption on files. However, both of these functions are provided by other programs--from which, indeed, code was stolen for those two "good" virals. Neither of the viral programs are as easy to use or control as the original programs, and both have bugs which must place them firmly in the malware grouping, for nuisance value, if nothing else. Currently, therefore, the utility of viral programs is very much unproven. This would, though, mean only that they are neutral, were it not for the lack of any demonstrable control. Methods of control have been discussed primarily by Fred Cohen, but even he remains unconvincing. The mechanisms generally are limited to environmental checks which can either fail, or be easily cut out of the program. Some have proposed "hunter" virals, to go after programs which "turn rogue", but a program which is corrupted will behave in unpredictable ways and a hunter program would likely consume a lot of resources, fail, or (most likely) both. (Cohen frequently cites viral "programs which have been running since 1986 with no ill effects" and speaks of a VCE (viral computing environment). There are two points to be noted here. One is that Cohen has not yet described his viral programs in anything like the detail he put into his earlier work, so there can be no independent assessment of his claims. The second point is that the very term, VCE, implies that a viral computing environment is substantially different, and should be kept separate, from the "normal" computing environment as it is currently known. A VCE may very well be a powerful entity, but it is still an unknown and unproven concept.) Computer viral programs have an inherent danger: that of reproduction and spread. If you study explosives, and pass along that knowledge, you also have to pass along the materials before there is any risk of a blast. Even then, the materials do not multiply themselves: when exhausted, another supply must be found. The same is *not* true of viral programs. These entities are *designed* to reproduce. And, unlike the study of dangerous animals, or even germ warfare, viral programs are built to reproduce, multiply and spread without the aid of a skilled, or even aware, operator. If you are careless with a deadly animal or weapon, it is still only a single danger in a localized area. If you are careless with a computer virus, it can spread world-wide. We do not use computers because they are smart. Computers *aren't* smart. Sometimes we use them because they can do calculations very quickly, but even this is only a special case of the real value of computers. Computers always do the same thing in the same way. They are repeatable. They are, in this manner, reliable. Even a computer error can be useful to us--so long as it always happens the same way. Consider, then, the computer virus. In order to reproduce without the informed assistance of the user, the virus must be, in the computer sense, transparent. It must operate without alerting the operator, or interfering with the operator's interaction with the computer. If the virus even posts a notice ("Hi! I am infecting object X!"), it has a nuisance value and is, therefore, not good. (Vesselin Bontchev notes that even such a notice, by possibly delaying a process, may have grave consequences far beyond annoyance.) If, however, the virus does *not* notify the operator, then the operator is not aware of some additional code in the machine. This extra code will have an unknown, and inherently unknowable, effect on the computer. The operations of the computer are, therefore, no longer repeatable. This is a Bad Thing (TM). Some will protest that I have overblown the danger of both the notification messages and the possibility of conflicts. The point that I am trying to make is that you cannot predict the harm which may arise from interference either with the operator or the programs. Software is digital, and is subject to catastrophic collapse without prior warning. For those without a background in computer risk assessment, an excellent overview for the non-professional is found in Lauren Wiener's "Digital Woes" (cf. BKDGTLWO.RVW). An intriguing compilation of the types of things that can go wrong is to be found in Peter Neumann's "Computer Related Risks" (cf. BKCMRLRS.RVW). At the very least, as Sarah Gordon points out, the virus is an autonomous agent, making decisions and carrying out activities according to it's own internal constructs and the intention of its programmer. This is very likely not in correspondence with your own intention, and is therefore an invasion of privacy. A number of virus writers will object that their creations simply are not harmful. Not only is it impossible to guarantee that your virus will not conflict with existing systems, you also cannot guarantee that a given system will not conflict with your virus. Almost all file infecting viral programs will interfere with applications which have an internal integrity checksum or a non-standard loader, and will cause those applications to fail. (An example of this is that Windows programs infected with DOS viral programs always fail to load.) The "Ohio" virus (a prior version of Den Zuk) was not intended to carry any destructive payload, but an unusual interaction with a certain network operating system caused fatal disk corruption. Since both Ohio and Den Zuk are examples of the often proposed "virus hunter virus", it should be clear that the concept of using a viral program to hunt down and disinfect other viral programs is not a good one. Historically, and statistically, virus exchange people have been careless and incompetent programmers. Remember that we are talking vx, here, and those viral programs which have been released into the wild. There may be, carefully hidden in the desk of a virus writer, the "perfect" and harmless virus. If so, we haven't seen it yet. The majority have obvious bugs, sloppy coding and derivative programming. Less than one percent are interesting for *any* reason; only a handful have unique styles of algorithms. And even these last have programming pathologies. There are two other reasons often given to justify virus exchange. The first is generally described as experimentation and education. The second is described as antiviral research, or, more commonly, assessment of antiviral programs. These arguments *do* have some validity, and should be examined. Ultimately, though, the reality fails to support the claim. The call for experimentation is somewhat tied to the argument for a "good" virus. Current viral technology may be crude and ridiculous, but how can it be improved if there isn't any work or sharing of results? Quite true. The vx community, however, have obviously not read or noted any programming journals or texts. Discussions of programming and algorithms are supported by well- annotated code fragments. You don't present a whole program to discuss a specific function any more than you send an entire car with a manual on auto repair. You certainly don't use encoded or "DEBUG script" object code: that has no explanatory value at all. And I have yet to see, in the vx materials, any discussion of legitimate and positive uses for viral technology, any discussion of control technology, or any discussion directed at ensuring that viral programs do not create conflicts. In regard to education, it is true that a study of viral programs is related to a knowledge of operating system internals, as well as assembly language programming. However, viral study *requires* such knowledge, rather than providing it. Giving someone a virus and expecting them to learn from it is akin to "teaching" a surgeon by handing him a scalpel and pointing at a patient. Even the vx "old guard" are beginning to realize this. Viral programs use normal computer functions. If you understand computers, a virus is trivial. If you don't, well ... As far as virus exchange tutorials go, well, let me put it this way. I am a teacher. Many of you will also know that I review technical books on a daily basis. Some are great, enough are good, many are bad and some are just plain awful. Only a few are worse, in terms of tutorial effectiveness, than vx "zines" (electronic periodicals). Recently, someone who makes his living pushing virus source code promoted a collection of viral programs by suggesting you could test antiviral programs with it. This, superficially, sounds like a good idea--if you don't know what *real* software testing is like. What do we know about the quality of this "zoo" (set of virus samples)? What do we know about the structure, organization, documentation and so forth? How many duplicates are there? Of course, we *do* want duplicates in some cases; we want every possible variation on polymorphs. (For Tremor, that works out to almost six billion files.) But then, this collection was on a CD-ROM. What a pity. The most successful viral programs are boot sector infectors, and you need to have real, infected disks to truly test for them. At a minimum, you'd want all seven "common" disk formats, in both system and non-system versions. That's fourteen disks--for *each* BSI. For all the length of this piece, it is still only an overview. And, for all it's length, it probably hasn't convinced anyone. Ethics education (it used to be called "values education"), in whatever form and however presented, has very little to show that it works. There are various theories and models of moral training, the most sophisticated probably being Lawrence Kohlberg's "Moral Development" schema. All, though, basically boil down to sitting around talking about ethical dilemmas. They may develop debating skills and rhetorical sophistry, but there is no evidence to suggest that any of these programs leads to any significant change in behaviour. While Kohlberg's model of moral development has the most detailed construction, its utility is questionable. His system is not so much one of values education as of values measurement. It is, therefore, a guideline for evaluating other ethical training methods rather than a means of instruction and change. Moral development is a six stage structure, assessing the type of reasoning which goes into ethical choices. The stages range from "fear of punishment" to "internal ethical principles". There is great difficulty, however, in determining the "stage" of a given individual. Most ethical discussions will be judged as having reasoning at all of stages three, four and five. This entire document, for example, could be dismissed as being level one reasoning since it mentions the possibility of the danger of virus distribution and could therefore be seen as a "fear of punishment" (negative consequences) on my part. On the other hand, most of Kohlberg's proponents dismiss level six, since even a psychopath could be said to be acting from internal principles. Kohlberg, himself, has stated that he does not know if anyone consistently acts from stage six reasoning. Probably the major reason for this is that modern society has no fundamental moral foundation. The most widely cited (and Johnson gives an excellent critique of it) is utilitarianism--"the greatest good for the greatest number". Leaving aside the difficulties of assessing such a measure, utilitarianism, along with all the other modern "humanistic" philosophies, has nothing to support itself. Why is "the greatest good for the greatest number" to be chosen over "what *I* want"? An alternative is deontology; ethical principles derived from the concept of duty. (Ironically, this philosophy, while arguably superior to utilitarianism, is limited to Kohlberg's stage four almost by definition.) Again, however, there is no underpinning to the concept of duty, itself. Ironically, the much maligned "Judeo-Christian Ethic" did have such a foundation for moral standards--God. The theistic universe may yet have the last laugh over the mechanical universe of B. F. Skinner's "Beyond Freedom and Dignity". Maybe Jesus *is* the answer--or there may be no answer. Bibliography Bontchev, "Are `Good' Viruses Still a Bad Idea?", Proceedings of the EICAR '94 Conference, pp.25-47, also ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/goodvir.zip Clarkson, "Windows Hothouse", 1994, 0-201-62669-1, U$34.95/C$44.95 - lots of artificial life fun with Visual C++ Cohen, "It's Alive!", 1994, 0-471-00860-5, U$39.95 - an intriguing, provoking and practical exploration of computer programs as "artificial life", but somewhat narrow Denning, ed., "Computers Under Attack", 1990, 0-201-53067-8 - collection of essays roughly related to security, also "the net" Ermann/Williams/Gutierrez, "Computers, ethics and society" - textbook for computer ethics course: not great Gordon, "Technologically Enabled Crime", 1994 Forester/Morrison, "Computer Ethics", 1994, 0-262-56073-9 - lots of great stories, but short on analytical depth Johnson, "Computer Ethics", 1994, 0-13-290339-3 - the basic work in the field, thorough coverage and good discussion starter Levy, "Artificial Life", 1992, 0-679-73489-8, U$13.00/C$17.00 - an interesting wander through fields studying artificial life but no strong points Neumann, "Computer-Related Risks", 1994, 0-201-55805-X, U$24.75 - exhaustive examples from the RISKS-FORUM Digest of potential technological perils Slade, "Robert Slade's Guide to Computer Viruses", 1994, 0-387-94311-0/3-540-94311-0, U$29.95 - chapter seven looks at the computer virus and society Thro, "Artificial Life Explorer's Kit", 1993, 0-672-30301-9, U$24.95/C$31.95 - good fun, but little analysis Wiener, "Digital Woes", 1993, 0-201-62609-8, U$22.95/C$29.95 - excellent introduction to the risks of software (A fuller bibliography on values education readings is available for those demonstrating a willingness to put some effort into it, since, frankly, it's a really disappointing field. Sarah Gordon's "Generic Virus Writer" paper has significant resources here.) copyright Robert M. Slade, 1995 Permission is granted to post this file, in full, on any system. ====================== DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 Author "Robert Slade's Guide to Computer Viruses" (US contact 1-800-SPRINGER) ------------------------------ End of RISKS-FORUM Digest 16.91 ************************