Subject: RISKS DIGEST 15.41 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 26 January 1994 Volume 15 : Issue 41 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Lightning on the Ethernet (eddy, not flo) E-Mail Fraud (Lori Carrig) Update on voter fraud in Costella County, Colorado (Bear Giles) Laptop Computer Could Explode (F. Barry Mulligan) Opening of European borders delayed by InfoSys problems (Bertrand Meyer) Canada loses satellites -- anyone have more info? (Alan Wexelblat) Risks of dynamic binding (Andrew Shapiro) New museum on cryptography (Jeremy Epstein) Is Global Authentication Impossible? (Li Gong) Re: Phony air traffic controller (Mark A. Bowers, Cameron Strom) Re: Smart Cars and Highways (Jerry Leichter) Telescript risks (Bob Blakley III) Re: Can SETI signals bear viruses? (Andrew Klossner) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Wed, 26 Jan 94 16:10:01 GMT From: eddy Subject: Lightning on the Ethernet We had our local unix-support by yesterday helping us out with a putative kernel reconfiguration; told me the following job after which he'd had to do the sorting out recently: The two principal departments of Maths here, pure and applied, face each other around a courtyard. Someone had bunged an ethernet link out the window of one and in the window of the other in order to get their PC in one attached to the ethernet in the other. When, in due course, we had a thunderstorm, the PC and the ethernet box on the other end of the link were both totally cooked. Fortunately, the damage stopped there. Let's hope they now stick in a gateway to connect the two departments so no-one will try that again. Eddy [and not Flo. Yes, An Eddy is of course a current running opposite to the normal flow. PGN] ------------------------------ Date: Wed, 26 Jan 1994 13:15:34 -0500 (EST) From: carrigl@fire.nic.ddn.mil (Lori Carrig) Subject: E-Mail Fraud Electronic Mail Fraud, by Lori Carrig With the advent of Electronic Mail we have several risks associated with this modern vehicle of information. Of these risks one is E-Mail fraud. Just like with Mail and Telephone fraud, Electronic Mail fraud has come of age. Before I diverge into this problem let me set an example of an incident I worked on: I received a notice from a user that she received E-Mail promoting computer chips for sale from a internet address. She had not received her items which she paid for and wanted to report it. She gave the following account: She had received and responded to this address about the sale of the described items. After several exchanges of E-Mail from the culprit the price was determined and she inquired to the method of payment for the desired items. The culprit explained that they would only take Money Order. The culprit would accept a check, but would not ship the desired items until after the check has cleared. A name and address was given, but no phone number, to send the check to. The culprit stated that they would ship the items after 5-7 days. After 9 days the victim sent an E-Mail message to the culprit and inquired if they received the check. A message was sent back stating that they did receive the check and was awaiting for it to clear the bank. After 30 days the victim had not received the ordered, and paid for, items from the culprits. The risk here is quite apparent. As with Mail and Telephone Fraud, E-Mail fraud can cause extreme losses to users. What would prevent such an incident? Well here are some of the ways I have seen: 1. Order from known companies like Intel, Microsoft, CompUSA, and so on. 2. Pay with an Credit Card. You have the right to cancel the payment within 30 days if the items have not been received. There is other risks associated with giving you Credit Card number out, but I will not address them at this time. 3. Request a phone number and call the vendor to confirm the order. The best prevention is number 1 above and common sense. Know who you are dealing with before any monetary exchange takes place. Items 2 and 3 above have other risks involved with them which, in turn, may be another form of fraud. There are other samples of E-Mail fraud, but I will not address them at this time. I will leave that for future releases. With the estimated losses to Computer crime ranging from $3-6 billion dollars(1) it is cause for alarm. If you suspect that you are a victim of E-Mail fraud, contact your local police department. Please note that only 11% of computer crimes are ever reported to law enforcement.(2) The opinions above are mine only and DO NOT reflect any other parties position. Lori Carrig carrigl@nic.ddn.mil Footnotes: (1) Publisher: Search, Sacramento, CA (2) Publisher: Law and Order, September 1990 ------------------------------ Date: Wed, 26 Jan 1994 10:19:50 -0700 From: Bear Giles Subject: Update on voter fraud in Costella County, Colorado [Followup on election fraud report from last summer (fall?).] A state grand jury in Denver has indicted eleven people for voter fraud in Costella County, Colorado. In 1990, the census found 2278 adults living in the county, but there were 2536 registered voters. Those indicted include: o County Clerk Roy David Martinez, charged with falsifying residency reports in the 3 November 1992 general election. o His wife, deputy clerk and recorder Mariconsuelo Stella Rodriquez, charged with allowing Martinez's sister, a non-resident of the county, to vote. o Costella County Commissioner George Valdez, charged with aiding and abetting voter fraud, threatening to withhold a county employee's pay unless he voted for Valdez, and enabling a jail inmate to vote absentee, all during the August 1992 primary. o former County Commissioner Ernest Leo Chavez, charged with helping an alien to vote absentee. Also indicted were former County Commissioner Samuel Gonzales and his wife Lisaida, Martinez's siter and brother-in-law, two sisters-in-law of George Valdez and one of the latter's husband. Lisaida Gonzales was registered to vote in both Costilla and El Paso [Colorado Springs] counties. The relatives of George Valdez were registered in both Colorado and California since the 1940s. Bear Giles bear@cs.colorado.edu/fsl.noaa.gov ------------------------------ Date: Wed, 26 Jan 1994 06:01:21 -0600 (CST) From: "F. Barry Mulligan" Subject: Laptop Computer Could Explode Source: Consumer Reports, Feb 94, p.125, "Recalls" column NEC Technologies laptop computers; Battery could explode and catch fire. Products: 13,000 computers, models PC-17-01 and PC- 17-02, sold 12/88-4/90. Model no. appears on bottom. What to do: Turn on computer with AC adapter discon- nected and allow battery to discharge fully. Call 800 237-2913 for replacement battery and $100 bonus. (The image of a laptop exploding has a certain horrid fascination.) /* barry /& mulligan@acm.org ------------------------------ Date: Wed, 26 Jan 94 09:04:11 PST From: bertrand@eiffel.com (Bertrand Meyer) Subject: Opening of European borders delayed by information system problems Source: Agence France-Presse, 26 January 1994 The Schengen agreement stipulates the opening of borders between nine countries of the European Community (the Twelve minus Great Britain, Ireland and Denmark). The agreement's implementation has already been delayed several times but was now planned for February 1st. A report of the French Senate's foreign affairs committee states that it won't be operational for another year. According to the chairman of the committee, Xavier de Villepin, the culprit is the computer information system, which is not yet "operational". [This is a politically charged issue, because of fears regarding security (read terrorism) as well as illegal immigration from outside the European Union. I haven't seen any details about the problems of the "computer information system". -- BM] -- Bertrand Meyer, ISE, Santa Barbara Subject: Canada loses satellites -- anyone have more info? This is from EDUPAGE, the summary service run for free by EDUCOM: > SATELLITES OUT. Geomagnetic storms caused by solar flares knocked out > Canada's two communications satellites within hours of each other. > Affecting broadcasters, phone and cable companies, and other business > subscribers, they began to question the reliability of satellite > communications in the context of the info-highway and examine more > land-based means of transmission. (Toronto Globe & Mail, 01/22/94 A1). Does anyone have access to the original Globe & Mail article cited, or more info from another source? Did this loss of equipment mean interrupted or lost service, or did everything just switch to land lines? When they say "knocked out," does that mean the satellite hardware is damaged, or just that the software got wiped? --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard, Media Lab, Adv. Human Interface Group wex@media.mit.edu 617-258-9168 an53607@anon.penet.fi ------------------------------ Date: Wed, 26 Jan 94 14:40:49 MST From: shapiro@marble.Colorado.EDU (Andrew Shapiro) Subject: Risks of dynamic binding A quick description of dynamic binding: When a program is linked (the object files are put together,) certain common routines (like the I/O calls) are copied from a standard library into the executable file. This is called static binding. Dynamic binding allows the library routines to be stored in one place and are joined with the executable only when it is loaded to run. Dynamic binding saves space and allows libraries to be updated without re-linking executables. They also can be deleted. The other evening I stumbled upon an interesting single point failure for Sun Microsystem computers. While working I distroyed the /lib/libc.so.0.15 file. To my surprise nothing works without it. I already knew that Sun's defaulted to dynamic binding at link time, I also knew that it was possible to suppress this option by using the -Bstatic keyword to the link editor, ld(1). What surprised me was that the static option had not been used when building any of the user commands. I would have expected some of the most basic commands like ls, cp, and either tar or dd to be compiled with static linking. If this were the case repairing the /lib/libc.so.0.15 file would be simple. Instead I was forced to reboot from tape, install the mini-kernel and then mount the filesystem and restore the file. I believe the engineers that developed the dynamic binding system understood the implications of *every* program depending on a single file and kept the static binding option to prevent this. However, if the OS designers never use the static option and the dynamic library is lost . . . Andrew T. Shapiro, CSES/CIRES University of Colorado, Campus Box 449 Boulder, CO 80309-0449 (303) 492-5539 andrew@gooter.metronet.org ------------------------------ Date: Tue, 25 Jan 1994 09:32:41 -0500 (EST) From: jepstein@cordant.com (Jeremy Epstein -C2 PROJECT) Subject: New museum on cryptography There's absolutely no RISK in this article, but I thought it might be interesting to RISKS readers. The 24 Jan 1994 *Washington Post* has an article about a new museum of cryptography at NSA. The author describes the runaround in trying to locate it, finding the usual problem of NSA phone numbers which answer with extensions and people who don't have names. The article then goes on to describe why cryptography is so important. The museum contains all sorts of gems of the cryptography trade, including some old ciphering machines, displays of Civil War use of SIGINT, Enigmas (including one that can be tried out by museum visitors), and a Cray X-MP. The museum is located in a building surrounded by barbed wire behind an old gas station near Baltimore. According to the author: The National Cryptologic Museum, reached by exiting the Baltimore-Washington Parkway east on Route 32 and heading behind the Shell station, is open from 9am to 3pm Monday through Friday. Some at NSA say you can reach it at 301-688-5849. Others at NSA deny that number exists. I haven't been there (if it in fact exists :-), and would be interested in hearing from others if it's worth the trip. --Jeremy Epstein Cordant, Inc. jepstein@cordant.com [I'm sure some readers will find risks. BTW, for old-timers, it was the Colony 7 motel. I am told it is indeed open to the public. PGN] ------------------------------ Date: Tue, 25 Jan 94 14:54:55 -0800 From: Li Gong Subject: Is Global Authentication Impossible? (Re: phony air traffic controller) In RISKS-15.40, John Stanley (stanley@skyking.oce.orst.edu) argued: If there were to be such a voice authentication system, the information would need to be readily available to every pilot. This includes ... several hundred thousand of them. In addition, ... If the information is that readily accessible, the bad guys can get it, too ... Contrary to this gloomy picture, past two decades of research in distributed computing, especially in naming and authentication, seems to suggest that (1) naming information can be made globally available and (2) authentication data can be widely distributed without compromising security (e.g., using public-key certificate technology). Li Gong, SRI International, Computer Science Lab, Menlo Park, CA 94025, USA ------------------------------ Date: Wed, 26 Jan 94 16:23:35 HST From: n911@pnet16.cts.com (Etc Bowers) Subject: Re: Spoofing Air Traffic Control In Vol 15, issue 40, Jim Wolper stated that it would be difficult to implement digital signatures into the IFF transponder system. The military has been doing this for many years now. There is an IFF mode in which there is an encrypted "code of the day" transmitted by the interregator set, to which only a properly keyed tranponder will reply. In a very similar way, the military mode of TACAN can encrypt ident and radial information to deny use of our TACAN to an enemy. And of course, the military can encrypt Global Position System transmissions to deliberately degrade it's use by non military users. So it's not that difficult, just expensive to implement. ETC Mark A. Bowers, Naval Computer and Telecomm., Area Master Stn, Eastern Pacific, Wahiawa, Hawaii mbowers@nctsemh-epac.navy.mil n911@pnet16.cts.com ------------------------------ Date: Wed, 26 Jan 1994 10:07:47 -40962758 (EST) From: syscrs@devetir.qld.gov.au (Cameron Strom) Subject: phony air traffic controller (Pereira, RISKS-15.39) > an out-of-work janitor pleaded guilty to giving false radio commands > to pilots On January 25, the Brisbane Courier-Mail reported the following: A teenager with a $70 radio in his bedroom intercepted air traffic control channels and told two airline pilots to abort landings. The 17-year-old air cadet, obsessed with planes, also gave false reports of planes in distress and falsely instructed other aircraft for two weeks in December last year. He had learnt how to intercept radio transmissions as a member of the air cadets and from his time in the air traffic control tower on work experience as a Year 10 student. The control tower had been aware that someone had been abusing the system in the area and had been on extreme alert to make sure the pilots received correct instructions. The lad has pleaded guilty to prejudicing the safe operation of aircraft. He is undergoing psychiatric assessment, and will be sentenced on March 28. Cameron Strom syscrs@devetir.qld.gov.au Brisbane, Queensland, Australia. ------------------------------ Date: Sun, 23 Jan 94 22:37:38 EDT From: Jerry Leichter Subject: re: Smart Cars and Highways (Kabay, RISKS-15.35) In RISKS-15.35, Mich Kabay reports on a Washington Post newswire story about the Government spending on an Intelligent Vehicle and Highway System, which is intended to provide a variety of advances leading up to the dream of computer-controlled cars. The article is sub-titled "Washington's Latest Billion Dollar Boondoggle", so we know right off how it will be slanted. The story is the flip side of the "sales job" articles one too often sees. Were the director of this program to write a press release, it would certainly discuss all the great potential, including the potential of parts of the system no one really has any idea how to build, and none of the problems. The Post article discusses all the problems, including all the problems of versions of the system no one would consider building, without considering any of the possible advantages. In fact, one can look through the article and construct a guide to "how to write an article about the RISKS of a newly proposed system". Thus: 1. Compare to a system everyone loves to hate - no matter how little it has to do with the issue at hand: "Government spending on the little-known Intelligent Vehicle and Highway Systems (IVHS) program is expected to exceed $40 billion over the next 20 years. (By comparison, in the first 10 years of the Strategic Defense Initiative, Washington spent $30 billion.)" A more relevant comparison might be to the expected outlay of money over the next ten years on, oh, repaving existing roads, upgrading bridges, and so on. Also, how much of this cost is for development, and how much for deployment? SDI was all development costs. Deployment of almost anything on the scale of the national highway system - even something as simple as traffic lights to help control entry at busy on-ramps - quickly runs into the billions. 2. Demand proof before anything at all can be done: "claims of improved safety are unproven" 3. Assume a system model that is known not to be applicable: "central computer failures could lead to massive accidents" It's hard to imagine any reason for centralized control of such a system. Has anyone actually proposed this? 4. Demand that the system solves problems that are outside of its purview: "proposed fuel savings from smoother driving could be lost through higher speeds" "minor attention given to smart public transport, priorities for high-occupancy vehicles" Even if this is true, so what? Fuel savings are a social good; so is higher speed commuting. A smart highway system would give society the ability to make tradeoffs between them, to any desired degree. In what way is this a negative? Smart public transport - whatever that might mean - would be a social good if we could get people to use it, but the fact of the matter is that most of the population long ago "voted with their feet" in preferring cars - and not "high-occupancy vehicles" at that - to public transport. This project does not attempt to join the long list of failed efforts to convince people that they really would prefer to be on a bus or train; it attempts to provide a better implementation of the choice they've already made. Again, why is this a negative? 5. When in doubt, name some big companies that like the idea - that can always be relied upon to generate uproar: "main proponent of scheme is IVHS America, supported by 500 organizations including IBM, AT&T, Rockwell, General Motors, Chrysler, Ford" 6. Always, always stress the dangers to people, but don't mention the hazards of existing systems. "Participants in RISKS will shudder at the thought of testing computer programs design to control thousands of cars in lockstep at 200 kph. I wouldn't enjoy being part of the beta-test population." "proponents concerned with limiting liability for failures" "I find the concern with legal liability an alarming indication of where we're headed." The current "human controlled" highway system kills, what, 50,000 people a year? It has no effective mechanism for keeping significant numbers of drunk, drugged, or otherwise incapable drivers from wreaking havoc. It has no effective mechanism for getting drivers to respond rationally to such problems as inclement weather. Dealing with the ice on the roads here the last week or so isn't nearly as scary as dealing with the idiots who think that four- wheel-drive will magically allow them to steer and stop at high speed no matter how slick the roads are. The legal liability issue grows right out of this: Under the current legal system, evidence that something is less risky than what it replaced is not considered relevant; all that's considered relevant is that the system that actually *is* in effect hasn't prevented some injury. The current driving system is tolerated because it spreads the legal risk. If a new system cut the risk 100-fold, so that only 500 people a year died because of system problems, virtually everyone would consider that an unalloyed good - but if the result were 500 successful, massive lawsuits against whoever created, installed, and ran the new system, it would quickly collapse. 7. Make the technical problems appear clearly insoluble: "Participants in RISKS will shudder at the thought of testing computer programs design to control thousands of cars in lockstep at 200 kph. I wouldn't enjoy being part of the beta-test population." "I wonder how much attention will be paid to deliberate or accidental interference?" "How will partial or total breakdown of the control systems be handled? Car-to-car signalling?" "Presumably information will be transmitted through radio-frequency modems. What will the unique identifiers be for each car. What happens if two cars have the same identifier?" "What methods will be put into place to prevent spurious instructions from being accepted by car controllers?" Sorry, but none of these strike me as particularly difficult problems. 200kph requires reaction times that are not a problem with even fairly stupid control systems. "Thousands of cars" are not a problem unless one visualizes a system that controls them all from a central location. In fact, traffic control is the ultimate distributed problem, since the automobiles involved are distributed all over the world. The short-term choices that an automobile controller must make involve information about at most a few tens of other automobiles. Sure, long-term planning of routes and such requires more global information, but this is not a safety issue, and is not time-critical. It is easy to design "fail safe" modes for automobiles when there is some kind of system failure; all that's necessary is to gradually slow to a stop. In fact, this is something we handle rather poorly today - consider what happens when a front tire blows out in heavy, rapid traffic, or the repeated instances of multi-car collisions when visibility drops. Almost any reasonable system would be an improvement, and would probably save lives. This also relates back to point 3, "Assume a system model that is known not to be applicable". While the article didn't happen to address this point, complaints about the difficulty of creating such systems usually assume that the most advanced form (full computer control) will exist in parallel with the current system (full human control, pedestrians, bicyclists) on the same roads. That makes the system much, much harder - but why would we wish to build it that way? Highways today already assume limited access; why would we not designate some highways - or perhaps lanes of existing highways isolated by crash barriers - for computer controlled use only? Really, I can't believe anyone is concerned about the difficulty of ensuring that every car has a unique identifier. If it bothers you, use a 512-bit id and have the car pick one randomly every time it is turned on. The chance of a clash should be comparable to the chance that all the molecules in the car's gasoline simultaneously happen to break apart in a spectacular fireball. It would also make it much harder to track a particular automobile. Then again, why does a car need a globally-unique identifier anyway unless you assume the model of a single, central controller? That leaves the security issues, which are of course quite real and worthy of significant concern and careful design. But do they really look daunting enough to make the whole project clearly impossible? One important effect of almost any technology is that it increases the "leverage" an individual has. This "leverage" can be used for many purposes, some of them malignant. What's important are the tradeoffs. As an interesting exercise, one can apply the seven techniques outlined above - there are undoubtedly others, like "argue that the system will disproportionately injure the poor" - to argue, early this century, that automobiles should not be developed to replace horses. For example: 2. Demand proof before anything at all can be done: We know how reliable horses are. Can you prove that you can build a gas engine as reliable as a horse? 3. Assume a system model that is known not be be applicable: It's one thing to keep supplies of hay and oats at home, but would you want everyone to keep a tank of gasoline at home to keep his car filled up? Think of the fire hazard! 5. When in doubt, name some big companies that like the idea - that can always be relied upon to generate uproar: Actually, you can list some of the same companies.... And so on. -- Jerry ------------------------------ Date: Wed, 26 Jan 94 16:03:19 EST From: blakley@vnet.IBM.COM Subject: Telescript risks I think the discussion of telescript risks here so far misses the two most important points: (1) It doesn't really matter whether telescript agents "directly manipulate the memory, file system, or other resources of the computers on which they execute"! If they're going to be useful as "agents", they're going to be authorized to use the interfaces of their host systems to do some amount of useful work. Presumably, since users don't want to administer authorization on a user-by-user basis when the potential user set is "everyone on the worldwide internet", either: (a) The telescript agent on most machines is going to be a "somewhat privileged" or "highly privileged" trusted program, with access to a useful set of system services, utilities, and applications, or (b) The telescript agent on most machines isn't going to have access to much useful functionality. If (b) turns out to be the default, then our worries are limited. The worst permutation of (a) is that everyone installs the telescript agent on his workstation as the equivalent of a "setuid root" program, which allows it to do anything it wants..... Then it's just a matter of the "bad guy" writing a program in the interpreted language which invokes the desired functions on the remote machine..... The bad guy will *of course* be able to do this -- the whole *point* of Telescript is to make it easy to write programs which can invoke arbitrary functions on remote machines. The point here is that regardless of how much *mechanism* support is built into Telescript, the real problem is the complexity of administering authorization policy in a network in which: (a) There is no central administrative authority (i.e. most machines have their own unique security administrators), and (b) The people generating requests (i.e. releasing telescript programs into the network) have no idea where those requests are going to end up. (2) But of course the really bad problem which isn't addressed by any authentication or access control mechanism is the problem of emergent behavior in the network. Nobody knows what the dynamics of a network filled with end-user-written, self-routing "semi-intelligent" agents is. My bet is that IP storms are nothing compared with the weather we're going to get when substantial numbers of these agents start roving around.... Usual disclaimers apply along with the following unusual one: The author is G.R. (Bob) Blakley III (Security Architect, IBM LAN Systems, Austin TX), NOT G.R. (Bob) Blakley, Jr. (Mathematician & Cryptographer, Texas A&M University, Bryan TX)! Phone (512)838-8133 t/l 678-8133, FAX 838-1040 ------------------------------ Date: Wed, 26 Jan 94 12:31:01 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Can SETI signals bear viruses? Some serious naivete here ... "You don't need to worry about spreading viruses if you transfer data disks (say, word processing or spreadsheet files) between computers." It's not so. People can, and do, spread viruses by carrying Macintosh data disks from one machine to another. Spreading viruses via PC data disks is a bit harder, but does happen. "Well, hopefully if it comes to that one of our Heroic Scientists will have the presence of mind to read the bloody code before they run it!" I have seen malicious programs whose source was written in such a way that a careful read wouldn't necessarily betray its malicious character. -=- Andrew Klossner (andrew@frip.wv.tek.com) ------------------------------ End of RISKS-FORUM Digest 15.41 ************************