From: MERC::"uunet!csl.sri.com!risks" 10-NOV-1992 19:16:44.00 To: RISKS-LIST:;@csl.sri.com CC: Subj: RISKS DIGEST 14.03 RISKS-LIST: RISKS-FORUM Digest Tuesday 10 November 1992 Volume 14 : Issue 03 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: "To ensure the continuing access of law enforcement" (Jyrki Kuoppala) Credit Thieves (Paul Robinson) Concerns about quality in products of modern technology (Ralph Moonen) New emphasis for SDIO (Diego Latella) Accountant's error catches thief! (Joe Grace) Cellular misinformation (Barry C. Nelson) Re: Key Registration (Alec Isaacson, Peter Wayner [2], Andrew Klossner) Re: Interesting/obscure interaction between users (Rich Kulawiec) 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. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). 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. ---------------------------------------------------------------------- Date: Tue, 10 Nov 1992 13:29:31 +0200 From: Jyrki Kuoppala, Helsinki University of Technology Subject: "To ensure the continuing access of law enforcement" [Re: Denning...] The Russian government is going to pass a law requiring furniture manufacturers to build microphones and radio transmitters inside every sofa, chair, and table manufactured. A high official from the Russian government was reported to say: We just aren't able to function any more without a law like this. After the Soviet Union ceased to exist, the United States government has hired over 50 percent of the KGB staff and we are losing the ability to watch criminals. They have the need, and they have the money, and they value experience you couldn't have gotten anywhere else. Thus, our law enforcement has suffered. When this law passes, we can catch all criminals even before they have time to commit the crimes. It is planned that at a later stage when Russia has the technology to do it, a similar law will be passed for dentists to install the same hardware in tooth fillings. For people who have doubts that this would be a return to the former Soviet Union policies of watching for political dissidents, the official says: Absolutely not. We have learned from our past mistakes. It is only natural that we want to maintain our ability to catch criminals in the changing times -- the changes in the job market are taking all our KGB men for a country where there's money and where there's a flourishing job market, and it's only fair we should keep our law enforcement at the high level we have managed to get it. Thus we are not even increasing our resources, we are just keeping them the same. The tapes will be used only to catch criminals, and a court order will be required before we will listen to the tapes. Trust us, we're the Government and we are here to help our citizens. The law also requires that if anyone sitting on a sofa or a chair, or at a table, speaks any other language than Russian, she or he must be able to provide an interpreter who will translate his talk to Russian if the law enforcement decides there's a legitimate need to listen to the tape of the conversation. To make this possible, the name and address of the interpreter must be clearly said aloud in Russian near the table/sofa/chair before each conversation in any language other than Russian. //Jyrki [Although April Fools' Day is still far away, Guy Fawkes' Day was last week. Mayhaps this is appropriate? PGN] ------------------------------ Date: Mon, 09 Nov 1992 22:23:37 EST From: "Message Center" Subject: Credit Thieves [also submitted to the privacy digests...] (Really Paul Robinson -- TDARCOS@MCIMAIL.COM) Article Summary, "The Credit Thieves" (Washington Post, Nov. 9, Page D5), "They Take Your Identity, Then Your Good Name." In "The Credit Thieves" article author Stephen J. Shaw asks if you have checked your credit rating lately; some thieves have been known to find people's personal information, then create new identities - and new credit histories - for some people. Apparently name and address is enough to be able to "borrow" someone else's credit information. Some so-called "credit doctors" charge $500 to find someone else with the same or similar name and a clean record, and give the buyer that person's credit record. Shaw declares personal exposure to credit fraud: his credit rating showed "almost $100,000" in credit, services and merchandise ("loans, credit cards, personal bank loans, plane tickets, home-entertainment systems, computers, clothes, furniture, cellular telephones and a slew of other consumer goodies") granted to "him" even though he lives in Washington DC, and the credit granted to "him" was to someone in Orlando Florida, and he's never heard of the things claimed to be charged to him. He only found out about the incident when he applied for credit with an organization and they asked him why he didn't declare all the OTHER credit cards and such that he has. Apparently almost anyone with access to a computer terminal with access to a regular credit reporting agency can probably find out your credit history. His "Credit Double" was only caught because he tried to buy a house using Shaw's name. The Secret Service is the agency that handles trying to catch people who do this. The "credit mugger" is in jail awaiting trial for four counts of bank and credit fraud. Happy ending, eh? NOT. Now getting rid of the inaccurate and fraudulent credit requests is a job in and of itself. "Equifax had deleted five of the bogus accounts, kept another four on my report and added three new ones. TRW told me that most of the disputed accounts had been deleted because the creditor had not replied to TRW's inquiry, but added that the 'creditor may re-report item.' stating , in effect, that the accounts could reappear in future editions." Trans Union did not have the incorrect accounts, but still had the Florida address. TRW also has his address listed as Florida. A New York State agency found six out of 17 credit reporting agencies which advertised would sell credit histories without any attempt to verify the purpose of the request. An executive at TRW told a 1991 Congressional hearing that "if someone is willing to lie to get a consumer report on another individual, there is nothing in the present law to act as a deterrent." Apparently it's not all that hard even to get someone's credit report legally. The Fair Credit Reporting Act (FCRA) allows anyone with "a legitimate business need for the information" can get your report; this includes prospective creditors and employers. "This loophole covers anything from renting an apartment to paying for something by check to joining a health club or a dating service. Reports can be ordered legitimately by employers checking on employees, insurance companies writing policies, someone trying to collect a debt, and government agencies deciding to grant any form of assistance or licenses." The article notes one can request not to be put in the list of "pre-screened" or "targeted" people that credit reporting agencies sell to companies that sometimes offer credit. You can also ask to be taken off mailing lists by writing the Direct Marketing Association, Mail Preference Services, 11 West 42nd St, Box 3961, New York, NY 10163-3861. They can also take requests just to remove your telephone number from some lists. The article recommends contacting each of the three major agencies twice yearly, and at least 6 months before a major purchase, because some of them don't get what the others have. If something is wrong, contact the creditor directly as well as the reporting agency. If you can't get something corrected, ask to have a statement inserted in your record. If you're not satisfied, you can write the Federal Trade Commission at Correspondence Dept, Room 692, Washington DC 20580. The major credit reporting agencies are: - Equifax, Box 740241, Atlanta GA 30374 1-800-685-1111 - Trans Union, Box 7000, North Olmsted, OH 44070 Regional Offices: - Box 360, Philadelphia, PA, 19105 215-569-4582 - 222 South First St., Suite 201, Louisville KY 40202 502-584-0121 - Box 3110, Fullerton, CA 92634 714-870-5191 - TRW National Consumer Relations Center, 12606 Greenville Ave., Box 749029, Dallas TX 75374-9029 214-235-1200 (TRW allows one free report a year by mail from) - TRW, Box 2350, Chatsworth CA, 91313-2350 Paul Robinson -- TDARCOS@MCIMAIL.COM [Disclaimer omitted...] ------------------------------ Date: Tue, 10 Nov 92 06:39 CST From: rmoonen@ihlpl.att.com Subject: Concerns about quality in products of modern technology I have been a regular reader of the RISKS forum for quite a while now, and the situation seems to be that more and more people are becoming aware of the risks associated with modern technology. However, also increasing is the amount of life-threatening accidents/near-accident/malfunctions/errors in computers and related other electronics. Some people have proposed measures to make sure certain quality standards are met. I can still remember the proposition for having software professionals register themselves as such. Much was said at that time, and the proposal got bombed. ISO has a set of standards (the 9000 series) for quality, which we adhere to within the company I work for. Others have proposed plans, but none really seem to get the attention they deserve, and if they do, they die a certain death after a while. After having read 'Zen and the Art of Motorcycle Maintainance' (highly recommended) and the ideas about quality described in that book, I think technology desperately needs to get in touch with reality again. I have thought about this, and have come up with a set of situations that can adversely influence the quality of a project or new technology. Furthermore, I would like to hear your views on the countermeasures I propose. Just to be clear, I am in no way a quality-expert, just a programmer who tries to keep in touch with reality, and reports as such. The way I see it, the following are major contributors to bad quality of a project/product: Before implementation: 1) Concessions during design w.r.t. costs, politics, human factors. I realise some consessions must be made sometimes, but I have seen a lot of projects go down because of too many concessions. 2) Too rigid a view of what is possible/impossible. As seen often here, some systems think it's impossible for people to have 1-letter names, resulting in chaos. Others think it is possible to positively identify people by just a subset of their personal data available. Many more examples are to be found, but basically they all boil down to the fact that the input/output requirements are context-sensitive. Don't forget the Fringe-Factor (TM)!! 3) Future needs are disregarded too often. "Works as designed" is a standard way of getting out of this, but isn't a solution. Some thought *must* be given to future needs when designing a project 4) Compatibility needs. If a product is intended to work together with a different product, it should be clear during design exactly how the other product operates. During implementation: 1) On the fly changes to the design, usually a result of too high a cost or implementors just not being up to their task. If you have a good design, stick too it, or change it only when it *adds* quality. 2) The tools to do the job turn out to be defective. In stead of replacing the tools, too often implementors are forced to use the old ones, thereby reducing quality of the end-product. 3) Mis-communication between implementors and supervisors of a project. Things are heard like "You want it next *week*?? I thought you said next *month*!!" Several variations on this theme come to mind :-( 4) Loss of oversight over project. Every implementor must have a general view of the totality of the project. The final quality is *his* responsibility. Details are OK, but don't loose the "feeling". After implementation: 1) Incomplete testing of the product before delivery. Too little time is taken to test the product, and a product will be under-developed when it reaches the marketplace. Combined with point 2 this leads to extremely counterproductive results. 2) Rigidity of supplier. After the product has been delivered and installed, a provider should support the project with a total commitment to quality. Usually this is done by means of a maintenance-contract or an update-contract, but I think it shouldn't stop at that. Too often a product is only then corrected, if the customer reports the failure, even if supplier knew about it long ago. A supplier should do everything in its power to ensure the integrity of the product. Alas, usually the supplier won't do anything, even if told frequently. 3) Untrained personnel handling the new product/project. After said product has been delivered, unknowledgeable personnel often get thrown in at the deep end, sometimes with disastrous results. While all these points are pretty straight-forward, when seen as a list, it immediately becomes clear where most manufacturers fail. While they don't cover all points, I believe the following countermeasures could increase overall quality. 1) Start design from specifications which are as context-insensitive as possible. 2) As I said before, don't forget the Fringe-Factor (TM). 3) Survey possible future needs *before* design. 4) Make sure you stick to the design, once it is accepted. If it costs more, you have failed in the initial estimate, and you should ensure that you can continue the project. It will pay off. 5) Check methodology and tools before implementation. 6) Make it exactly clear which secondary requirements there are to a project. Both the implementors and supervisors should have the best communication about this. 7) Make sure every developer of a product is aware of what part of the project he is working on, and why. Ensure he has at least a good working knowledge of the other parts of the project. 8) If the product is complex, then supplier should provide the client with an opportunity to give the clients employees and future users of it's product a training in the use of this product. If these points are taken well, I think we would see better products, which are not necessarily more expensive. Note that I haven't touched the subject of user interaction, but that's because I think it's a completely different field, and is more subject to psychology than technology. Maybe some net.psychologist can shed his/her light on this? Oh, BTW, if you plan on sending me email replies on this, do so to: accucx.cc.ruu.nl!hairy%knoware.ruu.nl It is my private email account, so my email won't clog up AT&T's machines. --Ralph Moonen ------------------------------ Date: Tue, 10 Nov 92 10:30:15 +0100 From: latella@cs.utwente.nl (Diego Latella) Subject: New emphasis for SDIO >From "Disarmament Newsletter - Newsletter of World Disarmament Campaign" United Nations Vol. 10, No.3 - June 1992 New emphasis for SDIO The US Strategic Defense Initiative Organization (SDIO) has moved to cut its funding for space-based systems in order to increase its ability to deploy a ground-based system in conformity to the United States Missile Defense Act of 1991. The system proposed by this Act would be in compliance with the Treaty on anti-ballistic missiles and would have the goal of providing a ground-based SDI system by 1996 with the capacity to defend most of the continental United States. This has lead to reductions in funding the "brilliant pebbles" space-based intercepter programme. This on my opinion seems extremely dangerous since 1) It speaks explicitly of a *deployment* program. 2) It is in *compliance with ABM Treaty*. 3) It speaks again of *defending most of the US*. 4) Being ground-based and after the (supposed) "success" of patriots in the Gulf War it may claim for *more credibility* than space-based SDI. It is my feeling the Scientific Community should once again mobilize as it did against SDI, being also conscious that its task will probably be harder this time (see points 2 and 4). Diego Latella, Univ. of Twente - Faculty of Computer Science, TeleInformatics and Open Systems (TIOS) Group, P.O. Box 217, 7500 AE Enschede - The Netherlands phone: +31 53 893755 email: latella@cs.utwente.nl ------------------------------ Date: Tue, 10 Nov 92 12:21:14 PST From: Subject: Accountant's error catches thief! I am taking an introductory Accounting course (enough groaning! :-) and actually its quite a bit of fun --- since accounting is basically an exercise in managing the risks of having and not having accurate information to run a business. Of course, the accountants try to be as exact and consistent as possible to uncover any inconsistencies (e.g., theft, loss, mistakes). However, only so much can be done before the costs outweigh the gains, so only so much is *really* done --- with the hope that that's enough and that everything will be alright. (This "constraint" principle is that of "Cost-benefit --- the value of a financial item reported should be higher for the decision makers than the cost of reporting it" [Fundamentals of Financial Accounting, 6th E., Short and Welsch, page 159].) Of course, this seemingly cut and dry principle is *really* a matter of judgment --- what may *appear* as diminishing returns may actually be very valuable information. To sum up, accountants *try* to walk the line between valuable information (on one side) and diminishing returns (on the other side) with as accurate, relevant information as possible. Unfortunately, accounting systems are easily abused by crooks. So, accounting also covers "Internal Controls" (this week's lecture :-), especially of cash handling (but other stuff too, e.g., inventory, supplies). The main approach to avoiding misappropriation of cash is the division of responsibility for cash collection and accounting (and other responsibilities too). A commonly observed example of this separation of duties: At most movie theaters, one employee sells tickets and another employee collects the tickets. It would be less expensive to have one employee do both jobs, but it would be easier for an employee to steal cash. [FoFA, p. 356] As you can see, these measures are very important and, unfortunately, can be very expensive to implement. So this week, our instructor (who is full of great anecdotes from his banking/loaning experience) related the story of a merchandise business where, despite separation of duties, the delivery person found a way to defraud the company. The scenario follows: The delivery person delivered goods to customers in return for checks and cash which he was supposed to hand over to the bookkeeper to record (separation of duties :-). Then the bookkeeper gave him the checks and cash to deposit at the bank --- with a slip from the accountant for the amount of the deposit (separation of duties). Instead, the delivery person withheld a check from the accountant and picked up a deposit slip for the reduced amount. Then, on the way to the bank to make the deposit, he "cashed" his pocketed check in via the deposit cash --- thereby maintaining the validity of the bookkeeper's deposit slip (but coming away with the cash equivalent of the "cashed" in check from the company's payments). The only inconsistency left by the scheme is that customers who have paid for goods, are recorded by the company as having an unpaid balance (when they have actually already paid). I don't know how long this scheme had gone on, but I imagine small discrepancies are overlooked by larger companies (cost-benefit constraint again :-). Ironically, as long as everything goes well, the thief gets away with his scheme. Of course, the error here is believing the "Internal Control" system is not flawed --- but practically speaking, cost-benefit constraint kicks in and keeps apparently working systems from being scrutinized (or the old, simplistic maxim "If it ain't broke, don't fix it"). However, eventually, our ever vigilant but imperfect bookkeeper made a mistake on the deposit slip (where an even number was odd or somesuch). I don't know the details (at all) but apparently the thief didn't catch the error (or it didn't matter whether he did or not) and eventually the bank and company had to do research to resolve the problem. Of course, the research led to discovering how customers thought they had paid but were recorded as not paying, etc., and the fraud and thief were discovered. I found the case amusing and apropos to RISKS since Accounting is a formal attempt at reducing risk through cost-effective, relevant information (trade-off flag immediately waving :-), "Internal Control" systems which are subtly subject to abuse, and the ironic *value* of making a mistake once in a awhile (perhaps even on purpose) to highlight areas taken for granted. In this case, "If it ain't broke, break it" [to make sure it *really* isn't busted] seems a propos! Of course, technology may help address these issues (while creating fresh ones of course :-), e.g., electronic verification of paid and unpaid balances between the company and its customers or even electronic payment (e.g., CheckFree), etc.. Joe ------------------------------ Date: Tue, 10 Nov 92 14:58:48 EST From: "Barry C. Nelson" Subject: Cellular misinformation The Boston Globe, 9 Nov 1992, had a human interest story illustrating some good uses for the ubiquitous cellular phones. In many places you can dial *SP for the State Police, and this had been credited with getting rapid assistance to accident and crime victims, as well as apprehending a dangerous escapee. They mentioned problems with routing 911 calls. What I found more interesting was a discussion about the Coast Guard preparing to adopt *CG as a maritime cellular distress number. A local official was quoted as saying that the existing broadcast channels will remain in operation because anyone nearby will hear you and the CG operates Direction Finding stations to pinpoint your location. Okay... But then he went on to say that cellular calls "only give you a point to point channel", leading one to the wrong belief that they couldn't DF a cellular user, and that nobody else could listen if they wanted to. -BCNelson P.S.: After a PGN talk at MIT recently, someone in the audience claimed that the FBI has multiple "trunks" attached to the local cellular hub in Boston and they can monitor both sides of a conversation by just typing in your number. Thank goodness that this is a democracy. :-^ ------------------------------ Date: Tue, 10 Nov 92 10:07:36 EST From: Alec Isaacson Subject: "End-Running" Key Registration Recently D.LONGLEY@qut.edu.au wrote about "How Teflon John Coped with Key Registration" which got me to thinking about _other_ ways to beat key registration, namely a cipher group method. (i.e. an "innocent" word has some other word or sentence associated with it). In that case, our criminal could send to his associate, "How is your dear Uncle Joe." The associate, or his computer, looks in the code table and sees that "your" = liquidate "dear" = soonest and the intended victim is (by pre-arrangement) the next name mentioned. The FBI could crawl all over a message like that with a microscope and not discover a thing. I can't see why this wouldn't work (unless it becomes illegal to write about non-existent relatives :). I welcome comments, since the sum total of my crypto experience comes from reading the spy novels on occasion. Alec D. Isaacson, Miami University, Oxford, OH AI4CPHYW@miamiu.acs.muohio.edu isaacson@rogue.acs.muohio.edu (NeXt Mail) ------------------------------ Date: Tue, 10 Nov 92 10:08:43 -0500 From: Peter Wayner Subject: ... on a way to foil the fbi... Actually, the FBI is very technically proficient. James Bamford tells a story about their cryptographic prowess in _The Puzzle Palace._ Apparently, the agents determined that the _only_ way communication could be leaving the criminals is through the shirts they sent out to be laundered. The FBI kept track of the shipments with great patience and finally figured out that the number of shirts of each color encrypted the message. 12. The 4 bit cipher feedback allows Teflon John to reduce his phone bill with more sophisticated approaches where more than 1 nibble is used per message. With 4 bit cipher feedback there is more control over the ciphertext so that the messages can be modified easily to produce the requisite nibbles corresponding to the ciphertext used by MAC the knife. ------------------------------ Date: Tue, 10 Nov 92 10:00:05 -0500 From: Peter Wayner Subject: And by logical extension... > Dorothy Denning suggested that anyone using high-level encryption over a > public network be required to register their encryption keys with some > agency. Steve Tepper writes: > Take this a step further. What's to stop the bad guys from creating their > own language? (Say something like Esperanto but based on Navajo instead of > Italian.) And what about puns, double entendres, and anagrams? Will metaphor, simile, metonymy, and synecdoche be the next to go? Peter Wayner [Don't forget the anecdoche and its antidoche, the cynicure. Actually, there are all sorts of cryptic messages hidden in RISKS, but few people seem to notice them. PGN] ------------------------------ Date: Tue, 10 Nov 92 13:30:49 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: FBI Registration The clever ruse that Dennis Longley discusses doesn't differ substantially from simply using a code within the cipher. If you're going to load encrypted information into the first few bits of innocent messages, you might as well just redefine the innocent messages. For example, "buy soybeans" might be code for "kill tough tony". Andrew Klossner andrew@frip.wv.tek.com uunet!tektronix!frip.WV.TEK!andrew ------------------------------ Date: Tue, 10 Nov 92 08:57:16 EST From: rsk@gynko.circ.upenn.edu (Rich Kulawiec) Subject: Re: Interesting/obscure interaction between users (Honig, RISKS-13.88, Leichter, RISKS-14.01) Jerry Leichter follows up on David Honig's discussion of the SunOS shared memory resources by noting that it is possible to recover from resource exhaustion by using various programs to locate shared memory segments which are (a) were not properly deleted and (b) are not in use. In particular, he mentions Ultrix's "ipcstat", which displays a list of known IPC objects. (The corresponding SunOS program is called "ipcs"; I believe that it's functionally equivalent.) The problem is, though, that the situation is worse than either David or Jerry mention. It is not only possible to create shared memory segments which persist when they should not, but it is also possible to do so in a way that is *invisible* to ipcs--but visible to programs like top and pstat, which can measure available memory. We discovered this by accident when attempting to diagnose a resource exhaustion problem that our principal in-house application appeared to trigger. The scenario works like this: the basic operations permitted on shared memory segments are creation, deletion, attachment, and detachment. In normal use, a master program would create a shared memory segment, and various subprograms might attach to and detach from it as they needed to. Eventually, the master program would delete the shared memory segment before exiting. However, if one process creates a shared memory segment, and a second process attaches to it and then deletes it *while still attached*, the segment is not freed, even though it is marked as such and is thus invisible to ipcs. (It's not freed when the processes exit, either.) It's possible to start another process which can still locate and attach to this ostensibly non-existent segment, which is surprising. It can be deleted without a reboot by running a program which iterates through all possible shared memory segment identifiers and attempts to delete each one, regardless of whether or not it appears to exist, but this is a rather drastic solution. (We've also discovered some additional scenarios which lead to roughly the same problem; all of this was under SunOS 4.1.1.) Rich Kulawiec ------------------------------ End of RISKS-FORUM Digest 14.03 ************************