RISKS-LIST: RISKS-FORUM Digest Monday, 4 January 1987 Volume 6 : Issue 2 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Source Code is Counter to Viruses & Trojan Horses (Hal Guthery) Viral VAXination? (Bryce Nesbitt) Who is entitled to privacy? (Andy Freeman) SSN / Passport / IRS ... (Joe Morris, Don Wegeng, Jean Marie Diaz, Martin Minow, Brint Cooper, EAE114, John Pershing) [ENOUGH, ALREADY!] 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 in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: Mon, 4 Jan 88 07:51 EDT From: "guthery%asc@sdr.slb.com" Subject: Source Code is Counter to Viruses & Trojan Horses To: risks@csl.sri.com As a little bit of reflection about the fact that almost all computers have clocks in them will show, there is no protection in trying programs out with write-only harddisks or with privileges turned off. Doing this only sets the hook deeper. In fact, anytime you run a program whose complete workings you do not and cannot understand you are at the mercy of the author of the program and you are at risk. One very good way to counter viruses and trojan horses is to insist on getting the source code of any program you run. This is summarized in the following pocketsize adage: IF YOU CAN'T READ IT, DON'T RUN IT There are NO good reasons why software vendors shouldn't give you the source code of any program they sell you. The reason they don't currently is because you could see what a mess the program really is. In 999 cases out of 1,000 they don't know everything the program does and they certainly don't want you looking over the code and telling them. For a moment stop and think of all the execute only software you run on your system. Think of all the companies from whom you purchased this software. Think of all the pressure you put on them for bug fixes, new features, and lower prices. Think about the translation of these pressures into pressures on programmers. Suppose one of these programmers decides to get just a little even ... an occassional bad number, a lost record once a month, a couple pennies moved from here to there just for fun, a scrambled directory entry once in a blue moon. If the program does what it purports to do, where is the check? The project leader? The manager? The president? The venture capitalist? You? And who is responsible? You! And what can you do with a bunch of object code? Turn off the harddisk? Scan the program for strings? Deny privileges? Piece of cake! We are marginally able to answer the question "Does this piece of software do what I want it to do?" but we are absolutely incapable of answering the much more important question "Does this piece of software NOT do what I don't want it to do?" Through this gaping hole in our capabilities enter viruses and trojan horses. It is historically interesting that I can get a handle on the first question without the source code but I can get nowhere on the second without it. As long as we willing to accept programs from software suppliers without the source code we, irresponsibly in my view, accept undue risk and invite disaster. ------------------------------ To: comp-risks@ucbvax.Berkeley.EDU From: bryce%hoser.Berkeley.EDU@ucbvax.Berkeley.EDU (Bryce Nesbitt) Subject: Viral VAXination? (Re: RISKS-6.1) Date: 4 Jan 88 07:52:09 GMT Organization: The Logic Foundation > (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) writes: > >Could a "harmless" CHRISTMA-like virus attack a VAX/VMS system? A >recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a >virus hidden in SHAR files which are _executed_ as .COM files to unpack >them. I'm surprised nobody has mentioned this: Around here we don't "execute" shar files to unpack them. Instead there is a handly little utility called "unshar". I use a version on both Unix and my Amiga microcomputer. It internally handles all of the "legitimate" commands that a simple file packing shar might contain (echo, wc, cat, if, test, #, exit, etc.). It is much less vulnerable to attack. To use the example of the poster, unshar would simple report "unknow command" if a "SET PROC/PRIV=ALL" was quietly inserted in the middle of the file. The comp.sources.unix and comp.sources.misc archives undoubtably have C source code for the taking. bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") ------------------------------ Date: Thu 31 Dec 87 14:36:48-PST From: Andy Freeman Subject: Who is entitled to privacy? To: risks@csl.sri.com [BTW - What happens if I send mail to risks-list@kl.sri.com?] The recent controversy over access to financial records of companies (the companies want to control it and some find this offensive) is somewhat similar to the continuing furor over records about people, except that popular opinion in the latter case is that the people should be able to control information about themselves. Is there an essential difference here and what is it? Is the corner gas station entitled to more privacy than IBM? Why? Are all the corner gas stations entitled to more privacy than IBM? (The former group is comparable in size to IBM.) Note that in the current case, companies collected the information about themselves while in most privacy invasion cases, the person doesn't collect the information. If one is going to argue on property rights alone, these companies are entitled to control access while people in the other case aren't. -andy ------------------------------ To: risks@csl.sri.com Cc: albert@harvard.harvard.edu Subject: SSN Required Disclosures Date: Mon, 04 Jan 88 16:27:05 EST From: Joe Morris (jcmorris@mitre.arpa) In RISKS 6:1, David Albert reports that a post office clerk claims that the disclosure of your SSN is no longer "optional" on the passport applications. I can't say whether or not it is required, but the clerk is out of line in any case. The law on disclosure requirements is unusally direct: o The law prohibits any Federal, State, or local government entity (supposedly including related entities like State-suppported universities) from denying any benefit or service because you didn't give your SSN, with certain specified exceptions. These exceptions are generally (a) where tax matters are involved; (b) for a driver's license, and (c) in certain cases where there was a pre-existing *legislative* requirement for the SSN. o Whenever a governmental organization requests the SSN, whether it is required or optional, you *must* be given what is called the "Privacy Act Notification". This must tell you: (a) whether the request for the SSN is mandatory or optional; (b) what will happen if you don't give it; (c) under what authority it is being requested; and (d) what will be done with the information being requested. The Federal income tax forms you just received last week contain a good example of a well-constructed, complete Privacy Act Notification. (I knew that the IRS had to be good for something!) o There are no restrictions placed on the private sector governing the request for your SSN. In other words, the passport application should have included a Privacy Act notification, regardless of whether the SSN was optional or required. After writing the above, I called the Department of State to see what they had to offer. According to the Passport Office, the SSN *is* required, as of this morning (1/4/88); supposedly the Privacy Act Notification is on the back of the application. The DoS staffer I talked to insisted that applications prior to today didn't require the SSN to be provided. I assume that an application without the SSN would merely be returned; I can't see them fining you for not completing the form. Incidentally, does anyone in NetLand know of any case law covering the SSN requests? In particular, I'm interested in whether there have been any cases involving state universities. Although I wasn't involved, a friend was told by the legal office of his state university employer that the law didn't apply to educational institutions, even if they were funded by the state. On the other hand, seeing how poorly the legislature funded that university, maybe the lawyer had a point... Joe Morris ------------------------------ Date: 4 Jan 88 18:37:09 EST (Monday) Subject: Re: SSN Required Disclosures To: RISKS@KL.SRI.COM From: Don Wegeng I saw a short article on this subject last week in one of the Rochester, NY newspapers (I can probably find it at home if anyone wants a more specific reference). As I recall, the article stated that the IRS is having problems tracking down American citizens living abroad who don't file income tax returns, so a law was passed which requires passport applicants to give their SSN. The article didn't mention a fine, but stated that until new application forms are available applicants who do not give their SSN will probably be contacted for this information by the IRS. It appears that the IRS and the INS are going to start sharing information, undoubtably by connecting their computers in some way. The potential RISKS in this have been discussed in this forum many times. /Don [Also noted by Roy Maxion. The following messages, for those of you who haven't already given up on RISKS-6.2, relate further to this topic. This is a very popular subject, and it keeps flaring up spontaneously in RISKS. Thus I tend to be tolerant for a while, but then wish to slow it down. The following flurry of messages is an effort in that direction rather than an encouragement to stimulate it further. PGN] ------------------------------ Date: Sun, 3 Jan 88 04:04:11 EST From: Jean Marie Diaz To: risks@kl.sri.com, anthony@alderaan.scrc.symbolics.com Subject: Re: mother's maiden name Reply-To: ambar@athena.mit.edu Usnail: 55 Grove St., Somerville, MA 02144 Nynex: (617) 623-6591 Funny, I was opening a checking account today, and noticed that question for the first time. When I asked why they asked, I was told that it was wanted "in case the bank wanted to verify who I was". (In case of an accident that cripples my writing hand? Well, maybe...) On a related note, someone can call BayBanks and make various inquiries about my account, and even change the address to which my statements are mailed, by knowing my account number and the amount & date of my last deposit. Sounds tricky enough? Not for those of us who use Direct Deposit to handle our paychecks... AMBAR ------------------------------ From: minow%thundr.DEC@decwrl.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) Date: 3 Jan 88 11:47 To: risks@csl.sri.com Subject: Mother's maiden name? Why does American Express want to know your mother's maiden name? When my pocket was picked two years ago, and my AmEx card, passport, cash, and travellers checks stolen, AmEx (Paris) asked the obvious questions plus my mother's maiden name. As I understand it, it's something you generally know, but the thief (who has your name, address, phone number, SSnumber, and a lot of other information) probably doesn't know. AmEx (or whoever) is assuming the risk of giving a new card out to an unknown person who might not have *any* identification at all, and they evidently feel that this simple "password" is an authenticator with a reasonable level of risk. Incidently, AmEx lived up to its advertisements. The U.S. embassy in Paris managed to get me a replacement passport at 1 pm on a Saturday even though I had absolutely no identification. The embassy officer even lent me $10 so I could take a photo and metro to my luggage (and money stash). If I remember correctly, they did ask for a mother's maiden name (or similar). Martin ------------------------------ Date: Sun, 3 Jan 88 13:12:06 EST From: Brint Cooper To: Henry Mensch Cc: risks@csl.sri.com Subject: [Henry Mensch: American Express security ...] [Coincidentally, Steve Anthony asked Why are Mother's Maiden Names Required? PGN] In registering patients for the first time, the Johns Hopkins Hospital in Baltimore asks for Mother's maiden name as well. This and other information is factored into an algorithm for assigning a patient identification number. The hope is that by using such information, the probability of two patients being assigned the same number is acceptably low. Why not just assign numbers sequentially? Inevitably, someone loses their plate. JHH wants to be able to retrieve their records by reconstructing the number, if necessary. Assigning a second number would mean that the patient has two incomplete sets of medical records in the hospital. Some physicians would know the old number, others the new. Imagine what a malpractice lawyer would do with that! ------------------------------ Date: Mon, 04 Jan 88 10:07 EST To: RISKS@csl.sri.com From: EAE114%URIMVS.BITNET@CUNYVM.CUNY.EDU Subject: AM/EX AND MAIDEN NAMES When you're filling out the forms, it helps if you remember that the MOTHER's MAIDEN NAME is essentially a password. [and therefore subject to all of the problems of passwords... PGN] There is no particular reason why you have tell the truth, as long as you remember what you DID say. ------------------------------ Date: 4 Jan 88 08:49:17 EST From: John Pershing To: risks@csl.sri.com Subject: American Express security ... From: Henry Mensch Does this mean that anyone who knows a bit about me can get my AmEx plate, too? No, it merely means that anyone who knows a bit about you can get a new AmEx card mailed to your house. (Of course, there's nothing preventing someone who knows your card number from sending AmEx a change of address notification, and then requesting a new card! However, this might raise some eyebrows over at AmEx...) Remember, too, that AmEx is liable for any fraud that is perpetrated in this way. They are taking a calculated risk -- trying to make life as painless as possible for their cardholders while maintaining a sensible amount of security. It has always seemed to me that AmEx strikes an extremely reasonable balance in this respect. John A. Pershing Jr., IBM Yorktown Heights ------------------------------ End of RISKS-FORUM Digest ************************