RISKS-LIST: RISKS-FORUM Digest Wednesday 23 December 1987 Volume 5 : Issue 82 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: NYT article on computers in stock crash (P. T. Withington) ...BAD PRACTICE to truncate anything without notice (Doug Rudoff) The spread of viruses and news articles (Allan Pratt) Common passwords list (Doug Mansur) Re: IBM Christmas Virus (Skip Montanaro) Cleaning PC's can be bad for your health... (John McMahon) PIN verification security (Otto Makela) Social Insecurity (Roger Pick) 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:, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Wed, 23 Dec 87 11:51 EST From: P. T. Withington Subject: NYT article on computers in stock crash To: RISKS FORUM An article in the Boston Globe yesterday (23 December) covers similar issues, but raises a few additional points which make me think that (as usual) the computer is only an unwitting accomplice and not the source of the trouble at all. Date: Mon, 21 Dec 87 21:48:36 EST From: hal@gvax.cs.cornell.edu (Hal Perkins) [...] Promotions [of portfolio insurance] worked: By October, between $70 billion and $90 billion was invested in funds using some form of the insurance.... The Globe article points out that when portfolio insurance was first "invented" it was dismissed in an article in Fortune (ca. 1980) as a "carnival act". Its inventors pursued its promotion however, and the "invention" of index futures allowed them to make the concept more palatable to fund managers (since they were no longer required to change the makeup of their portfolio to participate). Shortly to follow was the "invention" of index arbitrage, which provided a ready appetite for the portfolio insurers' future trading. My inference is that what legitmized the "carnival act" was not any understanding of its mechanism, but simply a track record. Unfortunately there are a large number of investors who believe that history is an accurate predictor. [...] "The problem was that everyone is working from roughly the same theories," said Peter U. Vinella, a partner at Berkeley Investment Technologies in Berkeley, Calif., which writes many complex trading programs. "They all get the same feedbacks. And that leads everyone to take the same action." Here is the nub. My inference is that as long as insurance and arbitrage were *unusual* investment policies, they actually "worked" by trading on discrepancies arising from imperfect information. Of course their success led to popularity, and eventually to the situation Vinella describes: all sellers and no buyers, the downfall of any Ponzi scheme. A Fear of Defying the Computer [...] "People get lulled into thinking, `My program says this will work,'" said Robert H. Mundheim, the dean of the University of Pennsylvania law school.... "And you don't have time to think through the assumptions that went into the programs -- if you understood them in the first place." The Globe points out that the inventors and primary promoters of portfolio insurance (LOR Corp.) actually did "sanity check" what their computers told them to do and held off making the massive futures sales the program directed. (I believe they realized, if only intuitively, that their algorithm was operating out of its useful range, because they had not forseen the discrepancies it was now receiving as inputs.) However, several of their licensees did exactly as the program directed, having been lulled into beliving in its infallibility, only to find there were no buyers. As the sell orders mounted, depressing the price, the algorithms, lacking any sanity checks, simply directed more sales. It's interesting to speculate whether the limited automation of the exchanges exacerbated the situation or acted as a governor to slow things down enough for conventional investors to react to the bargain-basement prices and finally put a floor under the madness. ------------------------------ To: uunet!comp-risks@uunet.UU.NET From: wiley!doug@uunet.UU.NET (Doug Rudoff) Subject: ...BAD PRACTICE to truncate anything without notice (Re: RISKS-5.79) Date: 23 Dec 87 19:12:49 GMT Organization: TRW Inc., Redondo Beach, CA About two years ago I was working on a project that required coding in PL/I. I had a problem with running out of memory while exectuting my code. After many hours of frustration I discovered the problem was that I had two procedures 'put_message' and 'put_page' (which called 'put_message') truncated to the same name. This was due to PL/I's truncation scheme of taking the FIRST four letters and the LAST three of a procedure. Thus, both procedures were identified as 'put_age' and I ended up running out of memory because of unintentional recursive procedure calls. Doug RUDOFF TRW Inc, Redondo Beach, CA {cit-vax,trwrb,uunet}!wiley!doug H: (213) 318-9218 W: (213) 812-2768 wiley!doug@csvax.caltech.edu [Recursively Call a spade a spade a spade ... but don't expect it to return. (If it weren't Christmas time, and it hadn't been pouring in LA, I probably would have refrained from annotating this message from RUDOFF THE RED{ONDO} KNOWS RAINGEAR.) Happy holidays to all. PGN] ------------------------------ Date: Wed, 23 Dec 87 12:01:59 pst From: ucbcad!ames.UUCP!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt) To: ames!KL.SRI.COM!RISKS Subject: The spread of viruses and news articles (Re: RISKS-5.80) >>The prank seems to be benign, and therefore beneficial. My contribution was relevant to the above passage: the fact that it was on the front page of a major metropolitan newspaper (The San Fransisco Examiner, Sunday 12/20/87) with a more or less in-depth article spread the implicit warning farther (sociologically) than the virus itself spread. (Granted, this metropolitan newspaper serves one of the most computer-literate parts of the country...) Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt [I think the major point about Trojan horses, viruses, and similar problems is that they are relatively easy to perpetrate, but potentially devastating on many systems. The cases we have seen to date are all rather benign (except for denials of service) or localized in effect (PC graphics ARF-ARF!). The lesson is that these vulnerabilities exist. However, the rather benign cases suggest that deeper concern is warranted. PGN] ----------------------------- Date: Wed, 23 Dec 87 11:59 EST From: Mansur@DOCKMASTER.ARPA Subject: Common passwords list To: risks@csl.sri.com I am interested in making a list of the most common passwords chosen by users. I'd like to see if anyone knows of any studies that have been done (I vaguely recall hearing of at least one such study). We are writing a program to check for poor passwords on our systems. Please send replies to: Doug Mansur -or- (Mansur@dockmaster.arpa) L-308, Lawrence Livermore National Lab., P.O. Box 808, Livermore, CA 94550P [At one time "Susan" was reputed to be the most popular American choice. I recall a British clipping citing dogs' names as popular passwords. However, since many prudent system managers now insist on randomly generated pronounceable passwords, your study might be dated. Furthermore, I hope no one is stupid enough to tell you what their password is. But past studies (e.g., Morris and Thompson, UNIX Password Security: A Case History, CACM 22 11 November 1979) have encrypted initials, dictionaries, etc., with great effect. If your system permits access to unencrypted passwords, your study might focus on that instead. PGN] ------------------------------ Date: Tue, 22 Dec 87 13:33:10 EST From: Skip Montanaro To: risks@csl.sri.com Subject: Re: IBM Christmas Virus (RISKS 5.80) Ross Patterson wrote (in RISKS 5.80): >(5) Is the Internet similarly vulnerable ? >>Not to this one. It plays on several things that the Internet doesn't have: >>1) A large number of IBM VM/CMS systems. ... >>2) A suitable file transfer system. FTP doesn't apply. ... >>3) A good method of determining targets. The CMS NAMES and NETLOG files ... The quasi-equivalent of this problem in UNIX systems (and most of the Internet, because of the large number of UNIX systems it contains) is the ubiquitous shar file, an ASCII packaging machanism used to transfer code and other ASCII files via mail and/or Usenet news transfer. The problem lies in the way users unpack shar files: they execute them. Needless to say, inspection of shar files before execution/extraction is highly recommended. There's nothing to prevent me from writing a shar file that purports to be a Christmas card. Execution of it might display the card, check out the contents of various mail-related files, (like ~/.mailrc and ~/mbox) looking for likely candidates to send the shar file, then recursively send it. In fact, the same scheme would work for most operating systems with a command language that could be executed from a file. UNIX systems are especially vulnerable, however, because of their large numbers. Skip (montanaro@ge-crd.arpa, uunet!steinmetz!sprite!montanaro) ------------------------------ Date: Wed, 23 Dec 87 07:40:53 PST From: fasteddy%sdcdcl.span@VLSI.JPL.NASA.GOV (John McMahon) Subject: Cleaning PC's can be bad for your health... To: RISKS@KL.SRI.COM The following "SAFE-ALERT" form was distributed at Goddard Space Flight Center (NASA - Greenbelt, MD) about cleaning PC's. The date was 7/29/87, alert number X7-S-87-01. "Recently an employee of this installation was cleaning his personal computer screen with a glass cleaner when the screen caught on fire. The computer had been in use for some time and had built up a static charge. When the employee went to wipe off the glass cleaner with a tissue, his finger hit the screen. This action discharged the static charge causing a spark which ignited the alcohol in the window cleaner. A total of 8 personal computers were checked, with only 1 other catching on fire." The installation mentioned above was the Naval Weapons Center in China Lake, CA. The action taken was to inform the employees about what could happen, and ask them to use a non-flammable cleaner. If there was a need for a flammable cleaner, then employees were advised to discharge the computer before spraying. John McMahon DFTNIC::FASTEDDY (Span) FASTEDDY@IAFBIT (Bitnet) ------------------------------ Date: Wed, 23 Dec 87 15:53 O From: Subject: PIN verification security To: risks@csl.sri.com A while back, I posted an article on ATM card security, promising to tell more as soon as I get the official security guide. Well, now I have the guide, and here are some findings, given somewhat verbatim since this document was distributed as "confidential": In Finland, there are two methods of off-line verification of PIN's. Both are DES-based, so they can be considered pretty secure (unless there are hidden trapdoors in DES - has the analysis behind its design been made public yet ?) The PIN verification is done by the "verification unit", which consists of a keypad for PIN entry, the magnetic stripe reader unit and the main electronics unit, which communicates with the local cash register unit. The document also specifies which "security modules" may be used in these verification units: Intel 8751H, Intel 8752H and AMD 9761H. Can someone who knows better tell what these units actually are ? DES-chips ? The first method of PIN verification is the same that is used in VISA- cards internationally: the card number, the PVV-version number (off the card's magnetic stripe) and the PIN number the customer has entered from the keypad are all munged through DES, using certain highly secret keys which are distributed by the banks. The resulting number is then compared with the PVV-number from the card's magnetic stripe, and if it is same, the given PIN was correct. The second method used is local to Finland, I guess. In this, the card number is encrypted with several highly controlled keys, resulting in the actual PIN that the client should have given. There are very strict rules on key control, for example the master key is divided into three parts and given to three people who each load their part to the verification unit ala bank safe keys. This document also specifies the encryptation that MUST be used for all message transmissions to/from the verification unit. This would seem to remove problems with faked messages etc. The only problem that would seem to arise is key security - if the keys become widely known, there goes the security. Generally, it would seem that this type of security is an overkill in practise. A local supermart is a good example: they are on-line to the bank so they can send payment transactions immediately to the bank computer, they use magnetic stripe readers to read credit card / bank card stripes, but they still use signatures for verification. The only reason I can think for this is that it's simpler for them. Hooray for minimizing of risks! A note on ATM's swallowing cards up: my girlfriend lost her card to another bank's ATM a couple of days ago, since she couldn't remember the new card's PIN right. She didn't want them to send the card by mail, since it would take a few days, so she called the bank the next morning and told them to keep the card, she'll come and pick it up. Then she just went there during her lunch break, showed ID, and they gave her card back to her, since the card was not "wanted" or anything. Banks over here seem much more cooperative then the american ones I've been to. A safe Christmas, Otto J. Makela, U of Jyvaskyla Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland Phone: +358 41 613 847 BBS: +358 41 211 562 (V.22bis/V.22/Bell 212A/V.21) BitNet: MAKELA_OTTO_@FINJYU.bitnet ------------------------------ To: risks@csl.sri.com Subject: Social Insecurity Date: 23 Dec 87 11:45:22 EST (Wed) From: rpick@ucqais.uc.edu (Roger Pick) I have been reading RISKS for a number of months and have noticed that the contributors seem to take it for granted that social security numbers cannot be required except in situations involving income. I would like to know what the basis for this common knowledge is. Is it a statute? A court case? Can you give me a name or a citation so I can look it up in our local law library? The reason I am looking for it is that my health insurance plan is demanding my children's social security numbers. I seek to keep their social security numbers private whenever possible in order to reduce the problems they will encounter if a Big Brother society should come about. (I give mine out without a second thought -- it is already in so many places that I would have no privacy anyway.) To be able to cite legal chapter and verse would significantly strengthen my case; the insurers are presently intransigent. Roger Alan Pick - QA & Information Systems Department, University of Cincinnati VOICE: (513) 475-7166 UUCP: {decuac,psuvax1!gatech!mit-eddie,philabs!phri,pyramid}!uccba!ucqais!rpick POST: QAIS - Lindner Hall, Univ. Cincinnati, Cincinnati, Ohio 45221-0130 USA [This question is like the Yes Virginia, there is a Santa Claus letter in the International Herald Tribune. Discussion goes back to early RISKS. PGN ] ------------------------------ End of RISKS-FORUM Digest ************************