Text File

RISKS-LIST: RISKS-FORUM Digest Wednesday 10 February 1988 Volume 6 : Issue 24

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Alarming Wenches and Risks of Lojack (Alex Colvin, Scott A. Norton) Re: Software theft (Roy Smith) Interleaving of Early Warning Systems (Ronni Rosenberg) Shuttle Security (Jan Wolitzky) Risk Study Centers (Curtis C. Galloway) Legal Software testing (David Lesher) Re: risks of helpful usenet software (David Herron) Grants-chaos (F.H.D. van Batenburg) Re: viruses (Chaz Heritage) CompuServe virus - more details et cetera (David HM Spector)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Wed, 10 Feb 88 10:28:02 EST From: Alex Colvin <mac3n@babbage.acc.virginia.edu> Subject: Alarming Wenches (RISKS-6.23)

> ... One of my bosses had his brand new, fully alarmed, 1986 Toyota Celica > removed from his driveway in Beacon Hill by a wench equipped truck in > the wee hours of the morning.

That's the most dangerous kind. Especially in the wee hours.

[Actually I noticed the typo, but liked it so much I left it as is. Sic (sic) it to me. PGN]

------------------------------

Date: Tue, 09 Feb 88 21:06:52 PST From: "LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@CUNYVM.CUNY.EDU> Subject: Re: Hub auto-theft lessons; $$ risks of Lojack

> ... He made it out the door only to hear the periodic beep >of his pendulum alarm muffled from inside a large van ...

The real point of this message: Notice how the thieves negated most of the value of the alarm by putting the car inside a van. Although the owner seemed to hear the siren, the thieves could drive through town without too much attention being drawn to them. If the van had been RF shielded, Lojack would have been defeated, too.

What does Lojack use for an antenna in the protected car, anyway? If it shared the radio antenna, or had its own, a simple snip could also disable the protection.

I'm not impressed by the security it provides, and of course there is the privacy risk to the owner originally mentioned.

LT Scott A. Norton, USN, Naval Postgraduate School, Monterey, CA 93943-5018 4526P@NavPGS.BITNET 4526P@NPS.ARPA

[Scott also asked for the name of the wench. PGN]

------------------------------

From: roy%phri@uunet.UU.NET (Roy Smith) Subject: Re: Software theft Date: 10 Feb 88 15:32:54 GMT Organization: Public Health Research Inst. (NY, NY)

> it is extraordinarily bad practice to fire someone and then not change > all relevant passwords, revoke their privileges, etc.

Actually, I would quibble with the order of operations. Change the passwords first, *then* fire the person. In the past five or so years, we have had occasion to fire two people who had access to sensitive material. In both cases, accounts were zapped and appropriate passwords were being changed while that person was in the office getting the bad news. It doesn't take long for a disgruntled person to do serious damage with a quick "rm -rf *".

Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016

------------------------------

Date: Wed, 10 Feb 88 11:41:00 EST From: ronni@CCA.CCA.COM (Ronni Rosenberg) Subject: Interleaving of Early Warning Systems

In RISKS 6.22, Ronald Wanttaja discusses a scenario in which "The Soviets blind most of the US Early Warning satellites. ... The U.S. immediately goes to high DEFCON. ... The Soviets do *nothing*."

I believe that if the U.S. goes to a high DEFCON, the Soviets automatically go to a higher state of alert. Part of the danger of such situations is that the two countries' alert systems are tightly interconnected and responsive to each other. This can have the effect of ratcheting the alert status ever higher and increasing tension, which greatly increases the risk that an inappropriate decision will be made.

------------------------------

From: wolit@research.att.com Date: Wed, 10 Feb 88 17:22 EST Subject: Shuttle Security

The subject of the self-destruct mechanism used to prevent runaway rockets (including space shuttle's boosters) from wreaking havoc was discussed previously in this discussion group. One very knowledgeable contributor posted interesting details of the mechanism, including descriptions of the radio link, with assurances that the high security of the system, including classification of the frequencies used, greatly reduced the possibility of inadvertently blowing up a rocket.

Now, according to the AP, a NASA security audit conducted in September found serious security violations at NASA's Marshall Space Flight Center in Huntsville, AL. The wire service story, of course, focuses on such hijinks as a safe for classified documents being used to store coffee money, but it also reports that 7 packages of microfilm classified "Confidential" were left unsecured for 8 months. Each package of microfilm contained 181 sheets, listing 4,205 confidential radio frequencies (personally, I'm always suspicious of such precise figures). The information belonged to various of the armed services, CIA, and NSA. The MSFC is responsible for processing the shuttle's solid rocket boosters, which include the self-destruct mechanism.

What does this do to a risk analysis of shuttle safety? In general, how many points do you take off for each month the key to your system is laying around unprotected? When things like this happen, do people really sit down and redo those calculations, or do they just run around covering themselves and hope the same numbers as before still apply?

Jan Wolitzky, AT&T Bell Labs, Murray Hill, NJ; 201 582-2998; mhuxd!wolit (Affiliation given for identification purposes only)

[Quantitative risk analysis is always dangerous -- particularly if the assumptions are questionable. The existence of a serious flaw may kill you, or it may lie lurking. Probabilities are not very interesting when you are dead. PGN]

------------------------------

Date: Wed, 10 Feb 88 15:23:01 -0500 (EST) From: "Curtis C. Galloway" <cg13+@andrew.cmu.edu> Subject: Risk Study Centers

From the Carnegie Mellon office of public relations:

"Carnegie Mellon University has received a $1.2 million grant from the National Science Foundation (NSF) to help fund its new Center for Risk Perception and Communication, aimed at improving how companies, workers, the public and regulatory agencies communicate about and deal with significant health and safety factors.

"The center's experts in engineering, psychology and economics will do basic research on risk communication. They will focus on danger areas whose hazards have been studied, including radon in homes, highway safety associated with seatbelts, dam safety, the potential for birth defects and cancer from power lines, and cancer risks from sun light and chemicals in the environment."

I wonder if they will include in their research the risks to the public in computers and related systems... Have "hazards been studied" in this "danger area?" It seems to me that there is a distinct lack of communication about the risks of using computers (with the exception of the RISKS digest, of course!)

Curt Galloway ARPA: cg13+@andrew.cmu.edu UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!cg13+

------------------------------

From: netsys!wb8foz@ames.arc.nasa.gov (David Lesher) Subject: Legal Software testing (Re: RISKS-6.22) Date: 10 Feb 88 03:57:34 GMT Organization: NetSys Public Access Network

Ms. Leveson neglected to mention the big problem with the ABA testing program. They charge many thousands of dollars for such an approval, and many small vendors can't/won't pay up. Hence, only large, well funded, companies offer 'approved' products.

------------------------------

From: David Herron -- Resident E-mail Hack <david@ms.uky.edu> Subject: Re: risks of helpful usenet software Date: 9 Feb 88 18:04:55 GMT Organization: U of Kentucky, Mathematical Sciences

Henry's comment about new vs. old usenet software hit home very strongly with me. I made a posting a couple of weeks ago advertising that we had perl available, and I cross-posted it to comp.sources.d, uk.wanted, ky.general and uk.general. Ever since I've been getting mail from machines all over the net which thought that one of those newsgroups was moderated. I've probably gotten over a hundred by now.

Each of these machines is an "older" one from back when the rules were a little bit different, and there were some hard-wired newsgroup names which were moderated. Or rather, their news software is "older" software... :-)

David Herron -- The E-Mail guy <david@ms.uky.edu> or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET

------------------------------

Date: Wed, 10 Feb 88 14:31 N From: <SBQBEB%HLERUL57.BITNET@CUNYVM.CUNY.EDU> Subject: Grants-chaos

In the Netherlands students are supported by the government with a small grant to live on, augmented with a low interest loan which should be paid back later. The amount of money depends upon the wealth of one's parents, the study results and many many more factors.

In fact, this legislation was so complex that the brochures which were distributed by the government to the universities only covered the most simple cases. After heated complaints from the universities the government finally produced and distributed a MS-DOS program to assist the information officers at the universities. However, this program seemed to give correct information only once out of six questions (NRC 14/8/87), so it was soon called the "Deet-flop" (Deetman being the responsible minister and flop having the connotation of failure). Clearly this program was of debatable value so desperate universities appointed a number of students to assist the information desks and some of those students finally produced in their spare time a much better program than the Deet-flop. This is in use now in the universities.

However the real pain in the neck was not the governmental information, but the department responsible for the actual distribution of loans and grants itself.

* R.Schipper, one of my students, showed me a letter which cut him out of any funds because the department assumed he had earned the ridiculous huge sum of f 756025.00 (about $400000) instead of f 756.25 in july alone.

* Another student was cut out of funds because her father was too rich last year. The fact that he got broke recently and was virtually pennyless now did not change anything.

* Another 2 students told me they just reported a change of address. This resulted in a temporary (9 month for one of them) stop of payment until the computer program could handle the update of this information.

* Some students who quit studying still got their monthly payments although they had reported their new status properly (Computable 19/1/88).

* Ms Ymke Dykstra (86 years old) got a grant of f 2250 for study although she didn't study at all (Computable 19/1/88).

Of course these students were not the only ones suffering from that grants & loans distribution system. One estimated that about 100000 out of the 550000 students had trouble because of this unreliable software system (Leids Dagblad 23/10/87). Apart from actual blunders, a major problem was that the computer system and organisation couldn't handle the load. So apparently the respons to any mutation was to freeze all payments until all previous arrears was made up. In this way many students didn't receive their monthly payment, but their complaints only increased the load. It was estimated that for example in august 130000 letters were left unreplied (NRC 13/10/87). Students who tried to phone couldn't get through either; in august 1.1 million phone calls were tried but only 60000 got through (NRC 18/9/1987), and those students who did get through were told that nothing could/would be done because the administration department "was probably working on it" and complaints should be done in writing (which would only worsen the chaos of course!). Many desperate students who didn't got any improvement in their financial situation personally travelled to Groningen daily (about 2 to 3 hours one way) to plead their case, but all in vain.

Nevertheless, the minister denied the occurence of any problems repeatedly until the end of 1987, when an investigation was started. It appeared that all the people responsible for the software had warned the minister repeatedly that the software could not be ready before 1987. The minister however, insisted upon a start one and a half years earlier, in the beginning of 1986 (NRC 15/12/87). This resulted in a total chaos of which many students suffered. In the meantime the costs of this project, originally estimated at f 20 million, increased to f 73 million (computerworld 1/12/87).

F.H.D.van Batenburg

------------------------------

Date: 10 Feb 88 10:17:11 PST (Wednesday) Subject: Re: viruses (RISKS-6.23) From: "chaz_heritage.WGC1RX"@Xerox.COM

It is now clear that certain software houses are using virus as a deterrent to software piracy. There is at least one commercial system (Softguard 3.00) designed to destroy the files of a user who attempts to copy software protected by it.

This activity is, in my personal view, unjustifiable; there is quite enough trouble with malicious amateurs as it is. I do not believe that any such system can prevent disc copying by purely hardware devices. There is no reason to suppose that a dedicated amateur could not break down the protection of the anti-copy system itself, attach it to hitherto unprotected software, and post the whole thing to CompuServe or whatever - thus creating another epidemic.

I have adopted certain policies which I would recommend:

1 If you can manage withut a hard disc, do so.

2 Buy only unprotected, 'professional' software products from reputable houses who advertise the fact that their products lack protection devices. Pay the extra cost cheerfully and expect a professional level of support from the software house involved.

3 If you run a commercial game program, power down the entire system for at least five seconds afterwards before doing anything serious. Virus, like RAM discs, may be reset-survivable.

4 If you detect a software house using virus in its products, then do (a) an immediate boycott; (b) as much adverse publicity as you can manage.

Software houses who trust their customers not to steal from them should be respected and supported; there are many in UK and with luck the number will increase. Software houses who use virus against their customers are conspirators to commit criminal damage and should be treated as such.

Chaz Heritage

Disclaimer: these are my personal views and not necessarily those of any other person or corporate entity.

------------------------------

Date: Wed, 10 Feb 88 15:45:41 EST From: David HM Spector <spector@vx2.GBA.NYU.EDU> Subject: CompuServe virus - more details et cetera

An update on the Macintosh virus on CompuServe (and other systems):

The virus mentioned in Risks 6.22 seems also to be in at least one other HyperCard stack that I found on a BBS in San Jose and and on GEnie, General Electric's Information Service. The stack is called "The Apple Product Stack" (or something similar) and claims to be a preview of some upcoming Apple products. (I am in the process of contacting the SysOps of the BBS to inform them of its presence.) What this stack does is show a badly scanned image of something indiscernable and then (in the background) installs a virus into your system file.

Later, I was horrified to find during a check of my MacintoshII at home, that the very virus I had reported about being on CompuServe was alive and kicking in **MY** Macintosh. [I feel like I have been violated!]

Upon setting a number of disassemblers to work on the virus itself, I was able to determine that its a date-triggered, self-propagating retro-virus. (Please pardon the abuse of the terminology...) Its characteristics and workings are as follows:

It is an "INIT" resource (for the uninitiated an INIT is a code segment that gets run by the Macintosh OS at system startup time). INITs are usually used to do things like start mail servers, screen blankers, patch OS bugs, etc.

The virus's method of transmission is (suprise, suprise) via floppy disks *or* by an infected system "mounting" any volume that contains a bootable system file.

It sets itself up as a running part of the operating system by modifying system traps. The code is set to do something {I have not yet figured out what, but it starts by showing a picture of some sort} on March 2nd, 1988. There seems to be a few data areas in the middle of the code which may get jumped-to and then do something else, but I haven't had time to explore it to that end yet.

If you try to remove it from a running system, and it tries to propagate itself, your workstation will crash since the virus code is not present to service the system trap request. And if you tansfer control to another system file/disk without write-locking it (in hardware!) first, you've just infected the other system!.

The best solution is the one suggested by Neil Shapiro, the Cheif SysOp of CompuServe's MAUG; replace the system files ASAP, preferably by booting your Macintosh from a write-locked floppy and copying a fresh system onto your hard disk and any bootable floppies you have around.

The really "clever" part of this, if you will, was the use of a HyperCard stack at the initial transmission medium. HyperCard is a realy nifty program that is extensible with XCMDs and XFCNs (external commands and functions) usually written in C, Pascal or Assembly to provide functionality not present in Apple's Standard HyperCard distribution. The stack called this "user supplied" function, and >>ZAP<< a perfectly useful feature turned into a weapon.

I wonder how many viruses exist in copies of Lotus-1-2-3 on IBM-PCs? I understand external functions may be added with either C or Assembly.

On a lighter note: I am looking into writing some detection programs (for Macs) to look for common things that the viruses in my "collection" do in a target program, and warn that a program under examination _MAY_ be less than safe. Not a certification by any means but perhaps a way to check for simpler viruses... (And of course, it would/should have built-in ways to make sure it was not itself compromised... if that's possible. Perhaps by some clever crc scheme -- I don't know right now, as its just an interesting midnight project idea.)

David HM Spector New York University Senior Systems Programmer Graduate School of Business Arpa: SPECTOR@GBA.NYU.EDU Academic Computing Center UUCP:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4 MCIMail: DSpector New York, New York 10006 AppleLink: D1161 Compu: 71260,1410 GEnie: XJM21945

------------------------------

End of RISKS-FORUM Digest ************************