Subject: RISKS DIGEST 15.40 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 24 January 1994 Volume 15 : Issue 40 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Special Issue of responses to items on spoofing! And April is still far away. THIS IS A "YOU CAN MODERATE IT YOURSELF" ISSUE. PERHAPS THE SURFEIT WILL CAUSE ALL THREE TOPICS TO EXHAUST THEMSELVES. NO "UNCLE" MAIL, PLEASE. PGN 1. Re: Spoofing Air Traffic Control (John Stanley, Wolper) 2. Re: Spoofing Telescript (Barry Margolin, Adrian Howard, Paul Barton-Davis, Geoffrey Speare, John Pettitt) 3. Re: Spoofing SETI (Someone at NASA?, Bear Giles, Mark Staltzer, Steven King, Steve Elias, Charles Bryant, David Honig, Mark Thorson, Jon Mauney, Andrew Klossner, Dan Keith, Adam BJ Quantrill) 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: 22 Jan 1994 00:01:21 GMT From: stanley@skyking.oce.orst.edu (John Stanley) Subject: phony air traffic controller (Pereira, RISKS-15.39) >This raises interesting questions of authentication. Wouldn't it be possible >to add to air traffic messages some kind of ``signature'' that would help >receivers distinguish between legitimate and bogus messages? If there were to be such a voice authentication system, the information would need to be readily available to every pilot. This includes not only those who fly for large commercial airlines, but to every private (even student) pilot. Any pilot who might use air traffic control (ATC) facilities would need to know this data, and there are several hundred thousand of them. In addition, for the same reason that visual flight rules (VFR) pilots must carry aeronautical charts for the area they fly in, they would need to have the authentication codes for the whole area. (In an emergency, you might wind up at ANY airport within the flying radius of your airplane, especially if that emergency was because you weren't where you thought you were.) If the information is that readily accessible, the bad guys can get it, too. An additional concern is that the airport vicinity is often not the place where you want to require from pilots the extra effort (or time) required to look up authentication codes before they follow instructions. Some of this problem may be solved by the use of digital printed data, which are in use in some aircraft. This will not filter down to the private aircraft for many years. ------------------------------ Date: Mon, 24 Jan 94 10:35:59 -0700 From: Jim Wolper (research) Subject: Re: phony air traffic controller Fernando Pereira makes the suggestion of adding a ``signature'' to air traffic control messages as a means of verifying their authenticity. This is an interesting suggestion. The comments below relate primarily to the Air Traffic Control (ATC) system in the US. The present system of air-to-ground communication has two components: VHF voice and UHF radar transponders. Currently, aircraft flying under Instrument Flight Rules (under which all air carriers and many supplemental carriers are required to operate) carry a transponder which is capable of replying to a radar sweep with a 12-bit identification code and its altitude. This is referred to as a ``Mode C'' transponder. It would be very difficult to construct an unspoofable authentication code for either of these systems. The FAA has plans to upgrade to ``Mode S'' transponders, which would give ATC a digital uplink capability. This would make it easier to implement a verification code, but I have no idea whether this issue has been discussed by the FAA. The original date for adoption of the Mode S standard was 1992, but there has been quite a bit of slippage. Mode S transponders will be much more expensive, of course, and smaller aircraft (both personal and corporate) will probably continue using Mode C transponders and voice communication for some time. Jim Wolper, Certificated Flight Instructor, Department of Mathematics Idaho State University Pocatello, ID 83209-8085 USA ------------------------------ Date: Sun, 23 Jan 94 17:30:18 EST From: Barry Margolin Subject: Safety in Telescript >1) The Telescript language is interpreted, rather than compiled. Thus, >Telescript programs cannot directly manipulate the memory, file system or >other resources of the computers on which they execute. Don't forget: that's what we all thought about fingerd. RTM, Jr. showed us to be wrong. And even ignoring bugs like this, interpreted vs compiled isn't the real issue. Postscript is typically interpreted, but since it has operators that access files and can manipulate the interpreter's standard dictionaries, virii can be implemented with it. Some of the access control features described may prevent these kinds of intrusions, but until we see more details I think we are be justified in being concerned. Barry Margolin, System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ------------------------------ Date: Mon, 24 Jan 1994 11:41:18 +0000 (GMT) From: "Adrian Howard" Subject: RE: Safety in Telescript (Valente, RISKS-15.39) >1) The Telescript language is interpreted, rather than compiled. Thus, >Telescript programs cannot directly manipulate the memory, file system or >other resources of the computers on which they execute. This is a bit of a red-herring. Just because a language is interpreted by no means implies that it cannot be used to produce worms/viruses. I have seen viruses in Unix Shell scripts and even BASIC programs! IMHO it is *far* easier for the average malicious idiot to produce a virus in a decent interpreted scripting language than by hacking around with compiled executables. The face that Telescript programs "cannot directly manipulate the memory, file system or other resources of the computers on which they execute" must be due to restrictions in the design of the language. They have nothing to do with compiled vs interpreted programming. If an agent has the capability to alter itself/other agents, it has to be manipulating the memory etc of the computer it is executing on. >2) Every Telescript agent (i.e, Telescript program that can move around a >Telescript network) is uniquely identified by a telename. A telename >consists of two components: an authority which identifies the "owner" of >the agent (e.g., the Personal Communicator from which it originated) and >an identity which distinguishes that agent from any other agent of the >same authority. The authority component is cryptographically generated >and cannot be forged. [...] I presume you are going to give some information on the algorithm used for producing the unique "telename" so we can feel a little more sure about the "cannot be forged" bit :-) Also, does the telename change for self-modifying agents (if such things can be produced with Telescript?) >3) Every Telescript agent has a permit which limits its capabilities. >Permits can be used to protect users from misprogrammed agents (e.g., an >agent that would otherwise "run away" and consume resources for which the >user would have to pay) and to protect Telescript service providers from >malicious agents. [...] I am presuming that "permits" (why not "telepermits" :-) are also encrypted in some way to prevent naughty people producing agents which fib about what they are allowed to do. Like Phil Agre, I too am "looking forward to the first few reverse-engineered Telescript products"! [Disclaimer: I have to admit my entire knowledge of Telescript comes from the two RISKS articles I've read, so apologies for the picky tone. To the peeps at GM, I do find the concept of an agent scripting language fascinating, and it's good to know that you are thinking about security issues.] adrianh@cogs.susx.ac.uk ------------------------------ Date: Mon, 24 Jan 1994 10:09:21 -0800 From: pauld@cs.washington.edu (Paul Barton-Davis) Subject: Safety in Telescript Luis Valente writes, in connection with Telescript: 1) The Telescript language is interpreted, rather than compiled. Thus, Telescript programs cannot directly manipulate the memory, file system or other resources of the computers on which they execute. Since we all know that sh, BASIC, awk, perl and tcl are completely free of security holes, we can know feel at ease knowing that, since Telescript is interpreted, and thus cannot "directly manipulate the memory, file system or other resources", Telescript is safe as houses. Presumably the reason that C is less safe is that it can "directly manipulate" [ sic ] the filesystem of a computer. echo foo > bar; { printf ("foo\n") > bar } fd = open ("bar", O_RDWR); write (fd, "foo\n", 4); -- paul ------------------------------ Date: Mon, 24 Jan 1994 13:49:23 -0500 From: geoff@omg.org (Geoffrey Speare) Subject: Re: Safety in Telescript > The authority component is cryptographically generated and cannot > be forged. As a regular RISKS reader, this sentence alone tells me all I need to know... (It sounds like General Magic is taking reasonable precautions against "ill-intentioned scripts", which of course means that dedicated people will be able to create such scripts anyway, and that some sites will be more vulnerable than others.) Geoff Speare, OMG, geoff@omg.org ------------------------------ Date: Mon, 24 Jan 1994 19:00:54 -0800 From: jpp@netcom.com (John Pettitt) Subject: Re: Safety in Telescript Luise Valente of General Magic writes: [about telescript] >1) The Telescript language is interpreted, rather than compiled. Thus, >Telescript programs cannot directly manipulate the memory, file system or >other resources of the computers on which they execute. Pardon? Since when has an interpreter been safer than a compiler? Any programming language capable of useful work is also capable of destruction. [this is known in our office as "Pages law of languages" after John Page who says it repeatedly] Valente the goes on to further document how cryptographic (presumably public key) signatures are used to ensure secure and limited processing of agents. However the asserts that forged messages are impossible, that is a very brave thing to say in the light of the history of such statements. Several questions spring to mind: 1) will the security be published and subject to external verification (see all the arguments about clipper)? 2) will the security be downgraded for export, if so could a compromised 'export' message run on domestic networks? 3) what is the vulnerability to social engineering? As has been proven people are always the weak link. 4) what provision will there be to stop re-chipped / 'tumbled' devices? I for one would be far happier with some clear discussion of risk rather than the classic "it can't happen response" we see so regularly until it does happen. John Pettitt - Email: jpp@netcom.com or jpettitt@well.sf.ca.us Phone: 408 236 3202 Fax: 408 241 0307 ------------------------------ Date: Mon, 3 Jan 1994 13:58:07 -0500 (EST) From: SYSTEM@LOWGMO.LARC.NASA.GOV Subject: Low risk of alien virus from receiving SETI signals The initial risk level from alien signals is very, very low. Since the hostile intelligences can not know the details of our computer systems, writing any kind of virus would be very nearly impossible. Indeed, achieving any kind of communication would be (will be?) very difficult. The few tests that have been conducted so far involve one scientist composing a message based on "universal" mathematical constants and relations. Usually this message is to be laid out in a square matrix, with stick figures of a human, blobs for our solar system, etc. Unfortunately, often other scientists can not decipher the message. Now consider that the intelligences trying to decipher the message might be a squid living 20 miles down in a Jovial type atmosphere. Also note that it took humans 10K years or so to discover that by using sign language they could communicate with monkeys. Next, communication will take a LONG time. Since we have been listening for a few years now, it is reasonably certain that we have no technologically advanced nearby neighbors, that is within 50 light years or so. So our hostile alien will have to guess the detailed operation of the computer(s) we will be using 50 or 500 years in the future when his message gets here. A certain amount of risk does exist. If the aliens are very much more intelligent that we are (possible with genetic engineering or more efficient evolution) and we develop extensive communications with them (hoping for some crumbs of their superior technology) then when they send a wonderful program for us to run with root privilege.... A very much worst case is given in "A Fire Upon the Deep" by Vernor Vinge where billions of worlds are destroyed by hostile programs via the galactic equivalent of the internet. The bottom line is, after we gain some reasonable level of communication with the whatevers, be very wary of Greek gifts, and/or offers of alien waterfront property. ------------------------------ Date: Mon, 3 Jan 1994 14:25:43 -0700 From: Bear Giles Subject: Can SETI signals bear viruses? > > [... But if everything in > SETI is interpreted properly as pure DATA, you don't need to worry. PGN] Is this a reasonable assumption? We've always sent "baby talk" messages, but then again we've sent very short messages. And we're barely a technological civilization; we've had radio for a century, computers for half that. Many people living today were born before the first digital computer was built! What about a society willing to run a sequence which contained a few terabytes of information, starting from a simple binary raster image and progressing to fractally compressed images (or an even more advanced technology) and possibly even a DNA dump? Can we really assume that SETI signals will be pure "data", and not the equivalent of a 9 track containing uncompress.c in plaintext, tar.c.Z, and then encyclopedia.tar.Z? (This is not an idle thought; a while back someone posted a bogus "SETI" signal to sci.crypt. It contained a primer in digital logic and could have easily been extended to give the specification for a computer.) Bear Giles bear@cs.colorado.edu/fsl.noaa.gov ------------------------------ Date: Mon, 3 Jan 1994 15:23:16 +0800 From: stalzer@macaw.hrl.hac.com Subject: Re: Can SETI signals bear viruses? Not to worry, if alien programmers are anything like human programmers, their viruses must contain bugs. Besides, I doubt any other species could create sendmail. -- Mark [Actually a much greater risk exists of April Fool's Spoofs coming from people on this planet. But the ultimate hoax would be one cleverly created by alien intelligence. PGN] ------------------------------ Date: 4 Jan 1994 22:06:56 GMT From: king@wildebeest.cig.mot.com (Steven King, Software Archaeologist) Subject: Can SETI signals bear viruses? (Cantillo, RISKS-15.36) Several people have refuted the idea of SETI signals containing a virus, but I'm not sure anyone has really explained *why* this isn't a problem. At least, I don't think there's been enough of an explanation for the lay-person who's view of computers has been molded by one too many episodes of Star Trek... Viruses are computer programs. Nothing more, nothing less. The have the property of being able to replicate themselves and, through crafty programming, "infect" other computers. What do I mean by "infect"? Simply that the programmer has found a tricky way for the program to get transferred to another computer without the operator being aware. This usually involves the virus hiding itself somewhere on a disk or in another program. Just like any other program, a virus must be run in order to be effective. Obviously the operator won't knowingly run a viral program. The virus's programmer uses a trick of the particular computer to force the virus to be run. Say the virus attaches itself to another program. It'll do this in such a way that when the operator thinks he is starting the benign program, he's actually starting the viral program. This can be done with varying degrees of sophistication, of course. As another example, say the virus writes itself to a boot disk. The virus's programmer will typically make it install itself in place of part of the operating system, so the virus is run instead of (or in addition to) the computer booting. So, the virus is just a program. It must be run. And, like any other program, it can only be run on a particular brand of computer. You can't run Macintosh programs on an IBM, and you can't infect an IBM with Macintosh viruses. (We'll ignore emulation programs like SoftPC for the purposes of this article.) Viruses aren't effective until they're run. You don't need to worry about spreading viruses if you transfer data disks (say, word processing or spreadsheet files) between computers. Viruses aren't *DATA*, they're *PROGRAMS*. In order for a SETI virus to be effective it must be run as a program. We're not doing that with SETI signals now, and I doubt we ever will. For one thing, what sort of computer would we run the SETI program on? I really doubt the Little Green Men use IBM compatible computers! Or any other sort we commonly use here on Earth. Even if there were a computer program (viral or benign) contained in the SETI data we'd have no way to execute it without an alien computer. This is the real reason we're safe. Even if the data stream contains a viral program we'd need to run it in order for it to be effective. And to run it we'd need the alien's computer. Okay, let's say we have some *REALLY* malicious Little Green Men out there. They've beamed up a 486 machine and have written a virus for it. They send the viral program down so our SETI antennas pick it up. The researchers here miraculously recognize 486 machine code in the data stream and run the program. Are we dead? 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! Or at least, they'll run it on a machine that's not networked to anything. Of course, if the aliens are capable of this in the first place they can probably do a lot worse to us than writing silly little computer viruses. Steven King -- Motorola Cellular Infrastructure Group ------------------------------ Date: Wed, 05 Jan 94 17:06:25 PST From: Steve Elias Subject: can SETI signals bear viruses Oh, that we really might have an opportunity to worry about picking up anything at all with SETI, never mind programs containing viruses or Super Mario Brothers 32767. Didn't congress just cancel funding the latest and very great SETI project that had only recently begun? [Yes, but various private sources are keeping it going. PGN] ------------------------------ Date: Thu, 6 Jan 94 16:03:43 HKT From: ch@hk.net (Charles Bryant) Subject: Re: SETI viruses There is an assumption in this discussion that a virus received by SETI would need a particular type of hardware to run (i.e. an electronic computer). It is possible, however, that it could use the human brain instead. This could happen either at an individual or a group level. At the individual level, most people have experienced a persistent tune which, once heard, almost forces them to hum it for some time afterwards. Imagine a more powerful effect where hearing the tune hummed by someone else is enough to propagate the effect. At the group level, consider Communism. From the number of countries which have tried it, it is clearly an idea that sounds correct initially, even if practical application proves less successful. We are obviously spreading this particular virus in TV and radio broadcasts which are spreading off into space continuously. There is also an assumption that a virus must be harmful. This is not necessarily so -- the only true characteristic of a virus is that it can only reproduce by using its host and a virus which helps its host might be more successful in some circumstances. In particular, if interstellar communication is greatly helped by a virus, such a virus would be much more likely to be received here than one which debilitates a civilization. ------------------------------ Date: Thu, 06 Jan 1994 12:28:54 -0800 From: David Honig Subject: Can SETI signals bear viruses? (Cantillo, RISKS-15.36) ... since the nearest star is 4 light years away, the operating system they developed for would be obsolete by that time... Although if they broadcast 8088-compatible virii... ------------------------------ Date: Thu, 6 Jan 94 21:03:39 PST From: mmm@cup.portal.com Subject: Re: Can SETI signals bear viruses? Although a computer virus passed through SETI seems unlikely, a human virus is not. If a book like the Bible, Dianetics, or Das Kapital were received, it could cause enormous harm. Instantly, large numbers of people (albeit slightly loony people) would see it as important received knowledge, perhaps even holy knowledge, and begin to act accordingly. The defense is obvious. We must beam copies of our most dangerous books into space. This will subvert and destroy alien societies before they have a chance to do the same thing to us! Also, we must evaluate the threat. Government scientists should set to work on developing the most "effective" stories possible, to see how dangerous they can be. Of course, this work would have to be extremely secret to prevent its accidental release. Mark Thorson (mmm@cup.portal.com) ------------------------------ Date: Tue, 4 Jan 1994 14:24:55 GMT From: mauney@adm.csc.ncsu.edu (Jon Mauney) Subject: Re: Can SETI signals bear viruses? (Cantillo, RISKS-15.36) This in turn sounds similar to Piers Anthony's "Macroscope" in which the recently-discovered-on-earth macron particle turns out to be a great communications carrier, and supports a sort of intergalactic Usenet. But most of the channels are jammed by a brain virus: access the information and you go nuts. Probably a lesson there for us :-) Jon Mauney, Mauney Computer Consulting mauney@csc.ncsu.edu (919) 828-8053 [Also noted by Bruce Grant (bgrant@umcc.ais.org), although the intended target was sentient beings rather than machines. PGN] ------------------------------ Date: Mon, 3 Jan 94 12:31:16 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Can SETI signals bear viruses? Some ideas about malicious agents within SETI data have been explored in depth in science fiction. One scenario goes like this: aliens send us terabytes of scientific and engineering data, including plans for constructing wonderful devices. We construct those devices and deploy them massively. The aliens invade, and activate a trojan horse in the devices. This plotline was used in "The Ophiuchi Hotline" by John Varley. -=- Andrew Klossner (andrew@frip.wv.tek.com) ------------------------------ Date: Fri, 7 Jan 1994 00:20:44 GMT From: tellab5!odgate!dbk@uunet.UU.NET (Dan Keith) Subject: Re: Can SETI signals bear viruses? There was a science fiction novel by astronomer Fred Hoyle called "A for Andromeda" (and a sequel, "Andromeda Breakthrough"). In the story, a SETI-like listening program detects signals from the Andromeda Galaxy. These are eventually decoded into instructions for a computer and its program. The computer is built, at which point it then builds an android which becomes the protagonist. The rest of the story doesn't have much bearing on the discussion, though. Dan "Bud" Keith dbk@odesta.com ------------------------------ Date: Fri, 7 Jan 94 15:50:36 GMT From: Adam BJ Quantrill Subject: Re: Can SETI signals bear viruses? (Cantillo, RISKS-15.36) ... but taking a Star Trek TNG episode as an example (!), the scientists were all too willing to find any way at all to run a genetically buried program on their computer. Presumably a scientist would try to build an emulator to run the opcodes. Are the SETI scientists sufficiently careful in their approach to build an emulator that could not be subverted by the 'executable' it runs? - Adam ------------------------------ End of RISKS-FORUM Digest 15.40 ************************