Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
>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.
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
>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
>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
Luis Valente <luis_valente@genmagic.genmagic.com> 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
> 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
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
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.
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
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]
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
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]
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.
... 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...
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)
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]
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)
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
... 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
Please report problems with the web pages to the maintainer