Subject: RISKS DIGEST 16.94 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 21 March 1995 Volume 16 : Issue 94 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Deutsche Bahnfires continue (Debora Weber-Wulff) Canadian Government Almost Spreads Virus (Colin Perkel) Too high-tech... (Bob Wilson) Reevaluating Our Trust in Computers (Cynthia P. Klumpp) Internet: Threat or menace? (Eric Raymond) Re: Latent risks of cost-benefit analysis (Steve Smith, David Chase) Re: The Prodigious Manchurian (Rob Slade, Bear Giles) Re: First "Bank" of Internet (Steve Holzworth, Rob Slade, Willie Smith) Information Security Tutorials (Sushil Jajodia) AMAST'95 Preliminary Programme available (Pippo Scollo) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 21 Mar 1995 12:08:28 +0100 From: weberwu@cha01.tfh-berlin.de (Debora Weber-Wulff) Subject: Deutsche Bahnfires continue [This is in response to a query from me to DWW on this subject. Thanks to Debora for sharing with us what she knows. PGN] The Deutsche Bahn AG, the German train company, has been working round the clock for a long time to a) electrify the state of Schleswig-Holstein, which is just north of the city-state Hamburg, and b) to install a full computerized train regulation system. The big traintable change is scheduled for next Sunday (March 26), when the daylight time change takes effect, I believe. They went on-line with the regulation system last week and all h*** broke loose. It was okay for the first few hours, and then suddenly went berserk. I don't have all the details, as I have only listened to radio news the past few days, but they ended up having to route all traffic around this major switching point. The train station in Hamburg Altona, where the diesel locomotives are removed and electric ones put on for continuing trains, or where most people just have to change trains, was put out of service. People had to take the S-Bahn or a bus to the main train station, and ended up missing connections. (And then we have the problem with the local trains being fuller than Indian trains because of a special super-cheap deal on weekends, but that's another and computer-unrelated story.) I do not know for certain if Siemens is the main manufacturer, but I suspect that it is them together with AEG. They just founded a company together with ABB in Sweden to combine all their rail knowledge. Yes, they subcontract out a lot, some to a little company in Kiel, a bunch to Third-World company (but this is just rumor). How could this pass the testing phase? Well, this is not the first time Siemens has boo-booed (remember the microphone system in the Bundestag? There have been many others). My personal opinion is that Siemens/Sietec does not have control of their Quality Assurance and there are too many programmers there that believe that they can do no wrong, and bosses who believe them, because it costs too much to actually do massive testing. German programmers tend to take it as a personal insult when a fault is detected in code that they have written. Companies like Siemens/Sietec exacerbate the situation. I repeat, this is my personal opinion based on unscientific surveys conducted during drinking and card playing sessions.... so nothing eminently quotable. There should be an article in Computerwoche (German language) soon about it when the CeBit smoke clears, they enjoy reporting about Siemens/Sietec disasters. I'll keep an eye out for more details. Debora Weber-Wulff weberwu@tfh-berlin.de ------------------------------ Date: Tue, 21 Mar 1995 17:46:09 -0500 From: colin.perkel@guildnet.org (Colin Perkel) Subject: Canadian Government Almost Spreads Virus The Canadian government's first attempt at electronic distribution of its budget last month could have created havoc -- but not because of the measures it contains. A virus was discovered about an hour before more than 5,000 disks containing budget information were to be sent to the country's major financial institutions. One expert is quoted as saying the situation could have been catastrophic for banks etc. The RCMP are investigating how the unnamed virus (said to be boot-sector or FAT destructive) had found its way onto the master disk being used to make copies. The master had passed two Revenue Canada virus scans but a last minute check by the company hired to do the copying and distribution turned up the critter. Given the super secrecy and security surrounding the budget, there are serious questions as to how this could have happened. The RISKS involved in the federal government spreading viruses are obvious! ------------------------------ Date: Tue, 21 Mar 95 09:23:21 CST From: Bob Wilson Subject: Too high-tech... I just heard on the radio an announcement of a new safety project for farmers. Farming is one of the most hazardous occupations, by usual measures, with a significant number of injuries and fatalities happening when farmers get off of a tractor or similar piece of equipment to do a brief task like untangling something, but leave the equipment running. The proposed fix? Use the GPS satellite location system, which will be used by a piece of equipment worn by the farmer and another on the tractor: When they move apart, the tractor gets turned off. I suspect "the risks are obvious", as well as the availability of MUCH simpler technologies to do the distance sensing if in fact that is a good thing to do.... Bob Wilson wilson@math.wisc.edu [This sounds almost as far-fetched as the completely computerized SUNDIAL I conjured up for an editorial in the ACM Software Engineering Notes many years ago, as an example of technological overkill. Ultimately, the sundial would have used GPS to provide automatic dynamic seasonal corrections dependent on longitude and latitude, would track its own movement (no pun intended), and would work at night by simulated sunlight. PGN] ------------------------------ Date: Mon, 20 Mar 1995 20:21:24 -0400 (EDT) From: "cklumpp1@vaxa.hofstra.edu"@vaxc.hofstra.edu Subject: Reevaluating Our Trust in Computers Computers have, in most cases, improved the overall quality of life for us. When a computer process goes smoothly we are amazed at the speed and accuracy of the machine. But when something goes wrong, it is human nature to want to place the blame upon someone or something. When the problem is minor we can usually laugh it off or write it off as a "computer error", whether or not this is actually true. But, when the problem has caused severe (life-threatening) consequences we need in depth explanations of accountability. Also, the number of people affected by computer errors can range from one person who is directly involved in the use of the computer - to many people who are innocent bystanders. If the operator is the only one inconvenienced by a computer error assuming it created a minor problem, blame can be shrugged off. While at the other extreme, if large numbers of people are affected by the error, blame is sought. Therefore, there are two determining factors which cause us to want to place blame for the occurrence of computer errors. One factor is the severity of the problem and the other one is the number of people affected. With the increasing involvement of computers in our daily lives the number of errors occurring is also increasing. Errors seen many times in the past are still occurring while new errors are cropping up with the use of new technology. The dependent relationships between the software, hardware, data input (whether it is by a person or computer generated), procedures, and the communication links [risks-9.61], create a very complex environment. The blind trust we have in computers and the people who operate or program them may need to be reevaluated. In other words, can and should we always trust a computer operator or a computer with the ever increasing processing of data which affect our lives and then look to blame when failure occurs? Or should we decrease or adjust the trust we place on data input and computers? While I was doing a search for articles at the library on the periodical database and happen to be short of time one night, the computer froze suddenly for no apparent reason. I had already spent 30 of my precious 90 minutes reading abstracts and marking (to print) the ones I thought were relevant. I had not yet printed the abstracts when the computer stopped responding to keystrokes. I asked the reference librarian if there was anything that could be done. He said "Not usually, but try [Ctrl] Z or [Ctrl] [Enter]." I did - but nothing happened. He shrugged. I shrugged and laughed, then moved over to another machine to start my work all over again...how fitting. I would not have enough time to make copies of the articles I searched for and would have to return another day. I probably should not have trusted the computer to get me smoothly through my work that night; I left no time for computer error expecting the computer to be 100% reliable. Cynthia P. Klumpp cklumpp1@vaxc.hofstra.edu ------------------------------ Date: 21 Mar 1995 15:24:55 GMT From: esr@netaxs.com (Eric Raymond) Subject: Internet: Threat or menace? (Mills, RISKS-16.93) In a recent comp.risks post, Dick Mills speculates that the stability of civilization up to now may have depended on the ineffectiveness of one-to-many communication, and that the Internet condemns us to drown in memetic garbage generated by kooks, fanatics, and evangelists. I suggest Mr. Mills think of it as evolution in action. The people -- and civilizations -- that survive will be those who learn and teach critical reading and thinking skills. This is strictly analogous to the selection effect of biological plagues. Subject: Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93) In a recent posting, Simson Garfinkel used a reference to Prodigy's former method of handling swap space to point out that certain types of online access systems leave you vulnerable. In today's issue, Frank Ferguson tries to indicate, using details of the MS-DOS FAT and delete function, that such a concern is invalid. They are, or course, both right, but Garfinkel is righter. While Prodigy never did have any specific function in their software to browse and return information from the user's computer to the company, the software did have provisions to automatically update software. This could (although it wasn't) be used to run other types of software without the user being aware of it. But we don't have to pick on Prodigy. Other commercial systems "take over" your machine when you run the front end software. This is, of course, done to ease the burden of use for the subscriber, but it does mean that the online service can basically do anything they want with your computer. (The same, of course, is true for any software, but commercial online systems have the advantage of being in communication with their own software while it is running on your machine.) We need not limit the discussion to commercial services. GUI (graphical user interface) systems tend to have a lot of security loopholes and hiding places anyway. The X system has provisions for a remote system to control your workstation. The various World Wide Web browsers, particularly the graphical ones like Mosaic, have the ability to both transfer files and invoke execution of programs. That's all you need for a really nifty virus/worm ... DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: Mon, 20 Mar 1995 22:18:44 -0700 From: Bear Giles Subject: Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93) I content that this behavior *is* a bug. The proof is in the public's reaction to finding bits of "their" files in the Prodigy cache area. To give a human metaphor, imagine a coworker who casually leafs through the papers on your desk while waiting for you to get off the phone. This might be nothing more than a nervous mannerism and he may be totally unaware of what he's doing, but very few people won't be seriously annoyed at him. To avoid even the appearance of impropiety, most people carefully stare into space (or read a magazine) in this situation. Prodigy didn't observe this behavior (which in the computer world would have been allocating the space and immediately wiping the current data); it grabbed some disk space and saved a few seconds by not wiping the existing data... ... and found itself tremendously embarrassed because it violated one of the prime rules of our society (regarding privacy). The fact that we're still discussing this years later proves how sensitive of a nerve it hit! In an era when computers were scarce resources and few people had frequent interactions with one, such behavior could be justified as a valid engineering tradeoff. But computers are now routinely used by a large part of the population, and it is incumbent on the programmer to observe the social conventions even if it proves to be moderately "expensive." Bear Giles bear@fsl.noaa.gov ------------------------------ Date: Tue, 21 Mar 1995 16:23:44 -0500 From: Steve Holzworth Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93) This "announcement" is so full of holes as to be ludicrous. 1) According to the NC Banking Commission, use of the term "bank", with a very few limited exceptions, is illegal for anyone but an organization that is a federally (FDIC) or state chartered, regulated entity. The NC Banking Commission has taken an interest in this announcement, and is forwarding the info to the FDIC... 2) "The alternative to personal credit cards for electronic commerce is based on an FBOI procured Visa (tm) Automated Teller Machine (ATM) card. The card is prepaid, PIN protected, replaceable, disposable, and good at over 200,000 Visa/PLUS (tm) ATMs in 83 countries. " Translation: 'you send us $x.xx to keep on account (with no interest accrued to you). We deduct purchases from this balance'. What happens if we disagree on the balance and/or dispute transactions? Because this an ATM card as opposed to a credit card, normal fraud liability limitations ($50.00 US) and disputed charge reversals are not in effect. If someone fraudulently charges against your ATM account, you potentially bear the full loss. Also, the "vendor" info, sent in response to the specified E-mail request, indicates that the ATM cards are not "rechargeable". When you run your balance down, you must buy a new one. FBOI charges a 5% commission to establish a new card for you (ie - the "setup" fee is 5% of the balance you wish to put on account; when that runs out, you pay another 5% for a new card). Since they charge vendors a 5% commission per transaction, FBOI is keeping 10% of all funds that move through their system. 3) "The safety of FBOI is ensured because access to ATM funds without possession of both the ATM card and the Personal Identification Number (PIN) is not possible. ATM cards are also better than credit cards because their purchase does not require the personal, financial, and employment background of the consumer." Here is how a transaction is instigated (from FBOI info): "*FBOI procedures for creating a vendor E-mail invoice* FBOI E-mail invoices are a two line message created by a FBOI vendor. Line one of the message contains the customer Internet E-mail address. Line two contains the transaction amount in US dollars. This message must then be encrypted, signed, in ASCII, and in Text using the PGP command "PGP -seat invoice fboi". The "invoice.asc" is then ready to be E-mailed to fboi@netcom.com with subject "invoice". FBOI will issue an E-mail transaction receipt." "*FBOI procedures for creating a customer E-mail check* FBOI E-mail checks are a two line message created by a FBOI customer. Line one of the message contains the vendor Internet E-mail address. Line two contains the transaction amount in US dollars. This message must then be encrypted, signed, in ASCII, and in Text using the PGP command "PGP -seat check fboi". The "check.asc" is then ready to be E-mailed to fboi@netcom.com with subject "check". FBOI will issue an E-mail transaction receipt." FBOI then reconciles the above transactions and sends payment to the vendor (or credits the vendor's ATM card). Note that FBOI recommends product pricing at around ONE US DOLLAR for items! (Almost-Freeware, anyone?) 4) "...In addition, consumers can reclaim their funds at any time using an ATM." At what service charge per transaction? What limitations on withdrawal amounts (how many transactions will it take to empty my account)? Any yearly fees for this privilege? FBOI info is rather vague in this regard. The only pertinent comment I saw was (pertaining to vendor payment): "... While the Visa ATM card as a payment method has many advantages (portable, anonymous, and cash in any country of the world), your ATM may not dispense the entire payment due to the exchange rate and possible ATM fees." 5) "...Those services will collect the consumers credit card information in advance because of Internet security problems." Since those are still credit card transactions, the consumer has much better dispute resolution abilities. 6) "FBOI transmits no sensitive information over the Internet and prevents forgery and impersonation by using Pretty Good Privacy, PGP (tm), software for all transactions. This freeware provides excellent authentication and anti-alteration security." The description of transactions as in (3) above may or may not be subject to spoofing. I'm not up enough on crypto to comment. 7) "In addition to the unsecured nature of the Internet, consumers should be hesitant giving out their credit card information to vendors of unknown credibility." You mean like FBOI?? Based out of a Netcom account (instead of a .com domain)? 8) "...since U.S. Postal Service and Federal Trade Commission mail order laws do not apply to the Internet." The laws may not apply to the Internet per se, but credit card transactions are still subject to all of the controls of typical "mail order" as is normally practiced via telephone. 9) "The First Bank of Internet (tm) is not a lending institution, and is not chartered." This says volumes.... (see (1), above). And finally: "When FBOI procures a Visa ATM card for vendor customers the card becomes their money. FBOI will be granted access to their funds through the FBOI customer agreement allowing FBOI to possess a duplicate card." ^^^^^^^^^^^^^^^^^^ ------------------------------ Date: Tue, 21 Mar 1995 13:50:53 EST From: "Rob Slade, Social Convener to the Net" Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93) The FBOI card does seem to address some of the security concerns for commerce over the net. The replacement of one number by another does not provide any particular safety, but the limit on the card does restrict the damage. However, inquiring minds want to know: How easy is it, aside from emptying the account, to cancel/change/get a new card? Is there a fee? Is there any recourse if someone empties the account before you do? Does the encryption apply only to the card number, or to the whole transaction, including time and date stamp? Does the encryption software come with the card? Is it a smart card? Do you need a card reader of some type? What platforms is the software available on? Is the user responsible for getting/setting up the software? By using PGP is the FBOI restricting its operations to the US? Is the version of PGP that they are using operating with the RSA algorithm, or another? Is the key size restricted? If this really does work over E-mail, why do you keep talking about ATM? (Does it only work over asynchronous transfer mode networks? :-) DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: Tue, 21 Mar 1995 08:15:38 -0500 (EST) From: wpns@roadrunner.pictel.com (Willie Smith) Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93) In Risks 16.93, fboi@netcom.com (Vinn Beigh) writes: >The card is prepaid [...] >The safety of FBOI [the non-chartered, non-bank company] is ensured ...by the fact that it's prepaid, and even if FBOI loses all the money in the account due to fraudulent transactions, it's _your_ money that's gone, not their 5[!!] percent! >The worldwide producers on the Internet can use FBOI services without the >expense of owning or renting a dedicated Internet server or a World-Wide >Web site. Yeah, just get an account on netcom and you're a business! C00L! >In addition to the unsecured nature of the Internet, consumers should be >hesitant giving out their credit card information to vendors of unknown >credibility. Giving cash to some guy with a Netcom account is OK? Maybe I missed the smiley, or the original submission was tongue in cheek... >since U.S. Postal Service and Federal Trade Commission mail order laws >do not apply to the Internet. Another safety net for FBOI. What a gig! Tell you what, I now announce the First International Bank Of The Information Supercollider, you send me money and I promise not to lose it. [The money, that is, not the Supercollider. PGN] Willie Smith wpns@pictel.com N1JBJ@amsat.org ------------------------------ Date: Mon, 20 Mar 95 10:28:42 EST From: jajodia@isse.gmu.edu (Sushil Jajodia) Subject: Information Security Tutorials INFORMATION SECURITY INSTITUTE Sponsored by: Center for Professional Development George Mason University Fairfax, VA 22030-4444 Intensive, Short Courses: o Information Security Principles and Practice March 27-31, 1995 Instructors: Marshall Abrams, Daniel Gambel, Sushil Jajodia, Harold Podell, Ravi Sandhu o Recent Developments in Information Security March 27-31, 1995 Instructors: Marshall Abrams, Daniel Gambel, Sushil Jajodia, Harold Podell, Ravi Sandhu o Practical Security in a Networked Environment April 3-7, 1995 Instructors: Marshall Abrams, Ravi Ganesan, Sushil Jajodia, Brian McKenny, Harold Podell, Ravi Sandhu o UNIX Security April 3-7, 1995 Instructors: Marshall Abrams, Ravi Ganesan, Harold Podell, Ravi Sandhu For further information, visit the Information Security Institute home page through mosaic at http://www.isse.gmu.edu/~gmuisi. ------------------------------ Date: Mon, 20 Mar 1995 16:50:49 +0100 From: scollo@cs.utwente.nl (Pippo Scollo) Subject: AMAST'95 Preliminary Programme available The Preliminary Programme of the AMAST'95 Conference (4th International Conference on Algebraic Methodology And Software Technology, Montreal, Canada, July 3-7, 1995) is available on the WWW at the following URL: http://www.cs.utwente.nl/data/amast/amast95/PreliminaryProgramme.txt The file includes abstracts of the invited talks, conference schedule, registration information and registration forms, and accommodation and travel information. The deadline for reduced registration fees is: Monday June 5, 1995 The file is also available by anonymous ftp: host: ftp.cs.utwente.nl username: anonymous password: your E-mail address directory: pub/doc/amast/amast95/ get file: PreliminaryProgramme.txt More information about AMAST'95 is available from the following sources: 1. For bulletins on current status of the conference: amast95-info@cs.concordia.ca Tools and Demos: grogono@cs.concordia.ca Registration: krishnan@cs.concordia.ca Local Arrangements: missaoui.rokia@uqam.ca 2. For subscribing to AMAST'95 mailing list: amast95-request@cs.concordia.ca ------------------------------ Date: 21 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 16.94 ************************