From: CSBVAX::CSBVAX::MRGATE::"SMTP::KL.SRI.COM::NEUMANN" 14-NOV-1988 23:44 To: MRGATE::"ARISIA::EVERHART" Subj: RISKS DIGEST 7.77 Date: Mon, 14 Nov 88 16:34:45 PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 7.77 Sender: NEUMANN@KL.SRI.COM To: RISKS-LIST@KL.SRI.COM Message-ID: <12446603446.11.NEUMANN@KL.SRI.COM> RISKS-LIST: RISKS-FORUM Digest Monday 14 November 1988 Volume 7 : Issue 77 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: WORM/VIRUS: UNIX InSecurity (beyond the Virus-Worm) (Klaus Brunnstein) Unauthorized Access (Dennis G. Rears) re: NY Computer Laws and the Internet Worm (Forrest Colliver) Re: NSA attempts to restrict virus information (Steven Bellovin) Risks of unchecked input in C programs (Bill Stewart, Bob Frankston) Worms & Ethics (Don Wegeng) One count, or multiple counts? (Richard Wiggins) The RISKS of jargon (Dave Horsfall) OTHER CONTRIBUTIONS: University of Surrey Hacker (Brian Randell) Re: UK vehicle-identification systems (Steven C. Den Beste, Franklin Davis) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:risks-i.j ... (OR TRY cd stripe: / get risks-i.j ... Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95). ---------------------------------------------------------------------- Date: 11 Nov 88 15:27 GMT+0100 From: Klaus Brunnstein Subject: UNIX InSecurity (beyond the Virus-Worm) Sitting far away from the `center of epidemy' (and not using UNIX), I observe with great interest the analysis of the `Virus Worm'. In FRG newsmedia, the New York Times article produced public uproar, with several newspapers and the magazine `Der SPIEGEL' (in its November 7 edition) speculating, that something similar might happen to the computers of banks, tax authorities and state agencies. Moreover, the damage is reported to have affected `more than 6.000 large computers connected to ARPANET', and additionally, Joseph Weizenbaum is cited saying that this virus may also affect the really sensitive military US-installations. Evidently, a large portion of the newsproducers is infected by the `Virus of Disinformation'. First lesson to be learned: the insecurity of relevant operating systems, well-known to experts since long time, must be disseminated from specialists to the computer profession. If even Edp people are not conscious of the risks imbedded in today's operating systems, we cannot hope for solid public presentation of such events. In my personal fight against usage of UNIX in processing sensitive data (such as in medical, economical and public applications), I usually find my audience deeply surprised when citing F.T.Grampp and R.H.Morris, who in their AT&T Bell Lab Technical Journal (October 1984) article about UNIX Operating System Security wrote, after analysing the merits of `open systems' such as UNIX: `Such open systems cannot ever be made secure in any strong sense; that is, they are unfit for applications involving classified government information, corporate accounting, records relating to individual provacy, and the like...' When I chaired, at the German Unix User Group annual conference in Hannover, September 1988, the session devoted to UNIX SECURITY, one speaker analysed that a Secure UNIX would hardly get a higher Orange Book classification than C2 or B1 because otherwise the restrictions and changes would produce something very different. A `security shell', as now planned by X/OPEN, is a contradiction in itself, because effective security must be implemented in the kernel. Moreover, real security deficiencies are even worse, as `most UNIX systems are far less secure than they can and should be', as Grampp/Morris wrote in 1984: while the SENDMAIL/DEBUG allows for worm applications such as network and remote system monitoring, fault analysis and maintenance, it may be the basis of even really harmful crimoid applications, such as Trojan Horses, Viruses or automated espionage programs. (While Gould hopes to get DoD class B1, sometime early in 1989, for its new Secure UNIX concept, someone told me that IBM's AIX has been rated B1; can anybody inform me, whether this is true?) Despite of such insight (even of their employees), several manufacturers try hard to sell UNIX systems to banks, medical institutions and state agencies, in conscious contradiction to Grampp/Morris insight. While specially protected `production systems' are neither available nor developped, the installation, first isolated but later integrated into complex systems, of such inherently insecure systems will inevitably produce a `big bang' in some not to distant future: the criminal potential is deeply embedded in the systems, more than in their abuse. While the Virus-Worm did evidently produce only limited damage (esp. `eating' time and intelligence during a 16-hour nightshift, and further distracting activities in follow-up discussions, but at the same time teaching some valuable lessons), the consequence of the UNIX euphoria may damage enterprises and economies. To me as an educated physicist, parallels show up to the discussions of the risks overseen by the community of nuclear physicist. In such a sense, I slightly revise Peter Neumann's analogy to the Three-Mile-Island and Chernobyl accidents: the advent of the Virus-Worm may be comparable to a mini Three-Mile Island accident (with large threat though limited damage), but the `Chernobyl of Computing' is being programmed in economic applications if ill-advised customers follow the computer industry into insecure UNIX-land. Klaus Brunnstein University of Hamburg FRG ------------------------------ Date: Sat, 12 Nov 88 13:37:18 EST From: "Dennis G. Rears (FSAC)" Subject: Unauthorized Access Dave Bozak writes: > Clearly the design and release of a worm is a violation of >section 156.10. The worm was released was intended to gain access to >machines without authorization and was designed to gain access to >material (host lists) for propagation of the worm. > Now maybe I am missing something here, not being a lawyer...so >would learned colleagues please clarify the legal issues involved >in this particular case? The key is "unauthorized access". The sendmail process from the target machine allowed him to access it. He did not access that process without authorization; he just gave it something it didn't want. Sendmail accepted it. Because of that, he did not brake that law. The main problem with making worms/viruses illegal is drafting the laws. What is authorized access? If a friend of mine on Computer "A" gives me his password; does that in itself give me authorized access? Since I am on the milnet I can fing, ftp anonymously, send mail to lots of computers. All of these actions I have implied authorization. When dealing with networks the laws have to prohibit actions once access is made not prohibit access. Dennis G. Rears: Computer Scientist, 1LT USAR & Civil Servant AT&T: 201-724-6639 SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806 ------------------------------ Date: Sat, 12 Nov 88 16:55:11 EST From: Forrest Colliver Subject: re: NY Computer Laws and the Internet Worm With respect to the apparently "obvious" breaking of laws in the Internet worm case, bear in mind that the FBI only has jurisdiction in cases which involve federal crimes, or in cases where a suspect crosses state lines in conjunction with unlawful activities which would otherwise fall into state or local jurisdiction. Thus, breaking of NY state laws would not automatically allow the FBI to begin an investigation. It does seem that the progress of the worm across state boundaries would allow the FBI to assume federal jurisdiction, but I suspect that without precedents to fall back on, the legal profession is proceeding with caution! F.C., The MITRE Corp., Washington, D.C. ------------------------------ Date: Sat, 12 Nov 88 22:49:54 EST From: smb@research.att.com Subject: Re: NSA attempts to restrict virus information The situation is rather worse than the Times and AP have reported. The NSA is exerting a great deal of pressure to have disassembler output from the virus (to say nothing of C source) available to as few people as possible. When they learn of a copy in a repository (say, available for anonymous FTP), they ask their contact -- perhaps an administrator, perhaps a name they happen to know at that school to remove it. If that person hesitates, or expresses a wish to contact the person who made it available, they immediately contact the president of the university, who calls the dean, who calls, etc. As best I can tell, they have no legal authority to order the removal. But they are not hesitating to bring as much pressure to bear as they can, to try to scare folks into complying. --Steve Bellovin ------------------------------ Date: Sun, 13 Nov 88 22:31:43 EST From: wcs@alice.att.com Subject: Risks of unchecked input in C programs In RISKS 7.74 Geoff Collyer wrote about the finger-daemon hole caused by gets's lack of checking on the size of the input, and called for gets's eradication ("A bug waiting to happen"). While the ancestry of gets is certainly dubious, scanf() suffers from the same problem as commonly used (do *you* always use %50s instead of %s? "man scanf" doesn't). I've always been dissatisfied with the printf/scanf family - field widths are hard-coded in the format strings, with no way to parameterize them except building format strings on the fly, and there's no nice way to read/print arrays except character strings. It would be nice to say int i, data[NITEMS]; char *string; string = emalloc(whatever); scanf("%nd %ns", NITEMS, data, whatever-1, string); and know it would read the correct amount of data into each array, and to write printf("%n10f\n", 4, data); instead of printf("%10f%10f%10f%10f\n", data[0], data[1].....); Bill Stewart ho95c.att.com!wcs AT&T Bell Labs, Holmdel NJ ------------------------------ Date: Mon Nov 14 10:05:25 1988 From: bobf@lotus.UUCP Subject: Re: Risks of unchecked input in C programs (RISKS-7.74) The "little care" necessary to use the string functions safely amounts to reimplementing them which renders them pointless but they are very dangerous in that the "not so careful" are so numerous. ------------------------------ Date: 14 Nov 88 16:52:23 EST (Monday) From: Don Wegeng Subject: Worms & Ethics In reference to the recent Internet Worm incident, I was going through my library last night and found that CACM vol. 25, no. 3 (March 1982) contains two relevant articles. The first is the well known Worm paper by Shoch & Hupp, immediately followed by "A Self-Assessment Procedure Dealing with Ethics in Computing," edited by Eric A. Weiss. In light of recent history this is an interesting coincidence. Perhaps we should teach Computer Science students to read the entire journal issue when they're reading papers on a particular topic. :-( /Don ------------------------------ Date: Mon, 14 Nov 88 09:51:32 EST From: Richard_Wiggins@um.cc.umich.edu Subject: One count, or multiple counts? The Federal law that's been mentioned as the likely tool for prosecution of Morris Jr makes the first transgression a misdemeanor and subsequent ones a felony. The question is, did Morris invade hundreds of computers, or did he invade one network? As they say, "the network is the system." And it appears that he fired only one salvo -- albeit with 3 warheads. -- Rich Wiggins, Systems Programmer, Michigan State University ------------------------------ Date: Fri, 11 Nov 88 14:17:00 est From: Dave Horsfall Subject: The RISKS of jargon One of the RISKS in the use of computers is that it engenders a jargon that is at odds with community acceptance e.g. "ram", "mouse" etc. Here is an example of such a RISK that is the other way around, taken (without permission) from the "Backbytes" page in "Computing Australia", Nov 7, 1988: ``Well, it sounded like an opening. Some chipocentric people have difficulty accepting that computers aren't the centre of the universe (Whoops! Is IBM reading this?). Or perhaps it's just that the jargon of the public service is enough to throw even computer aficionados (masters of their own gobbledegook). Whatever, DDP's state-of-the-art Canberra rep thought he had the makings of a sale recently. Spotting a Dept. of Arts, Sport, Environment, Tourism and Territories [ yes, Australian bureaucracies are like that! ] advertisement inviting tenders for the "supply and installation of a restricted keying system", Richard Presser's white-haired boy thought: "We've got just the thing, our Rode/PC!" This esoteric device delivers dedicated data entry system performance, which is to say, it's a keying system. At least in computing argot. That very day he wrote off requesting more details and, of course, tender forms. To his great astonishment, it turned out what the department actually wanted was 108 locks for lockers and and other equipment at the Fraser (ACT) Primary School. -- Dave ------------------------------ Return-Path: <@CSL.SRI.COM:B.Randell%newcastle.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Thu, 10 Nov 88 19:14:00 GMT From: Brian Randell Subject: University of Surrey Hacker There has been a lot of recent publicity in the U.K. about the arrest of a hacker at the University of Surrey. There were stories about his investigation by Scotland Yard's Serious Crimes Squad and by the U.S. Secret Service, and much dicussion about the inadequacy of the law relating to network hacking - as far as I know he has only been charged with offences relating his unathorised (physical) entry to the University buildings. An article in today's Guardian newspaper that is based on an interview with the individual, one Edward Austin Singh, reveals that his techniques were simply based on a program which tricked users into unsuspectingly revealing their passwords. "I wrote a program that utilised a flaw that allowed me to call into the dial-up node. You always do it by phoning, never by the network. The dial-up node has to have an address as well, so we were calling the address itself. I called the dial-up node via the network and did it repeatedly until it connected. That happened every 30 seconds. It allowed me to connect the dial-up node at the same time as a legitimate user at random. I would then emulate the system." He used to run this program at night, and specialised in breaking into Prime computer systems: "I picked up about 40 passwords and IDs an hour. We were picking up military stuff like that, as well as commercial and academic", he claims. This enabled him to get information from more than 250 systems world-wide, and (he claims) in concert with an underground hackers network, to "access virtually every single computer system which was networked in the US - thousands and thousands of them, many of them US Arms manufacturers". The article states that "Prime Computers have so far declined to comment on his approach to them or his alleged penetration of their computer systems, until the American Secret Service completes its enquiries." Brian Randell ------------------------------ Date: Mon, 14 Nov 88 09:16:05 -0500 From: denbeste@OAKLAND.BBN.COM Subject: Re: UK vehicle-identification systems I find Chaz's description of the new system in Britain for toll-roads very interesting, to say the least. I have some interesting questions: 1. As I understood it, what we have is a radio handshake between each car and fixed tranceivers at the entrance and exit from the toll-road, presumably connected to a computer billing system which mails you a bill each month. What if you move and don't tell the computer your new address? 2. The idea is that with this mechanism it won't be necessary for the car to stop or slow down, as we must do here on the Masspike with traditional toll booths. More interesting is that it will presumably work in heavy traffic at high speeds. Not only won't it be necessary for the car to slow down, it can't do so without causing an accident. So if for any reason the handshake fails, the system has no recourse. Which leads to the interesting speculations: 3. The handshake happens at a certain radio frequency. What happens if the car happens to carry a low-power RF noise generater at just that frequency? 4. What happens if someone figures out how to get into their car's tranceiver and change the signature? It doesn't even have to be a valid one because there isn't any way for the highway to stop the car or log what it is. 5. What happens to cars which have crossed the Channel from France? Here in Massachusetts we have people who register their cars in New Hampshire to avoid the property tax (illegal, by the way); will Brits be registering their cars in Brittany to avoid the highway tolls? 6. Everything screws up. I can see the following scenario: John drives the A13 (or some other typical highway designation - I made this one up based on, sigh, Monty Python) to work every day. On Friday he gets on it (handshake succeeds) and drives home and gets off it (handshake fails for some odd reason - a nearby lightning strike just during the handshake?); Monday morning he gets back on it to go to work (another lightning strike louses up the handshake - isn't the weather *terrible* this time of year?) and gets off it near his job (handshake normal). What does the computer see? It sees John getting on Friday evening and not getting off until Monday morning. John sure must have driven a lot of miles that weekend - let's bill him big. 7. Just what WILL the computer do with a partial transaction - get on but don't get off, or vice versa? I can think of many ways this could happen. 8. Since there will be some cars on the highway without tranceivers (French etc.) then the system can't scream when it sees one. What is to keep someone from driving an ice-pick through their tranceiver with a hammer, or much more simply, pulling its fuse or clipping its power lead? Will the British meter maids start carrying little tranceiver-testers around checking every parked car to see if its tranceiver will handshake? The mind boggles. (I think that pulling the fuse is the best answer - that way you can plug it in again just before the yearly equipment check.) Frankly, it sounds like the greatest target for hackers since the ARPAnet! Steven C. Den Beste, BBN Communications Corp., Cambridge MA denbeste@bbn.com(ARPA/CSNET/UUCP) harvard!bbn.com!denbeste(UUCP) ------------------------------ Date: Mon, 14 Nov 88 14:52:19 EST From: fad@Think.COM Subject: UK vehicle-identification systems In his 10 Nov 88 RISKS contribution, Douglas Jones discusses optical and microwave barcode scanner devices for collecting tolls from cars. He states: The risk of such sensors as police devices depends to a great extent on how easy it is to instrument locations in the roadway without the driver being aware of it. Why not make use of such a system voluntary? If I had a choice between lining up to drop coins in a gate vs. driving through a barcode-reading gate, I'd choose the latter, assuming it meant I wouldn't have to come to a stop. But anyone who prefers anonymity could always use the regular toll gate (where presumably no one is writing down license plate numbers) and not install the barcode on their vehicle. The principle seems to me to be that if you are potentially diminishing someone's privacy, they should have a choice about it, and the costs and benefits should be made clear. --Franklin Davis Thinking Machines Corporation fad@think.com ------------------------------ End of RISKS-FORUM Digest 7.77 ************************ -------