RISKS-LIST: RISKS-FORUM Digest Thursday, 24 December 1987 Volume 5 : Issue 83 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Another article on the Christmas Virus (Mark Brader) Social Insecurity (Willis H. Ware) Expert systems (Peter da Silva) Most-common passwords (Rodney Hoffman) Permissions and setuid on UNIX (Philip Kos) UNIX chroot and setuid (Michael S. Fischbein) [HAPPY HOLIDAYS -- RISK-FREE, but maybe probably not RISKS-FREE] 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 18:28:31 EST From: msb@sq.com (Mark Brader) To: risks@csl.sri.com Subject: Another article on the Christmas Virus [just in time for Xmas] [In the spirit of the season, I am including this now rather old-hat and somewhat ill-informed note for a few more background details. It is interesting perhaps more for what the press can do to an incident than for the incident itself. Happy holidays to all. RISKS will take some vacation -- unless something really startling happens. PGN] I have been handed a clipping from the (Toronto) Globe and Mail's "Report on Business" section. I don't have the date, but Texaco Canada Inc. closed at $31, up $4.50, on the other side of the page. The clipping is of the Quidnunc column by Bud Jorgenson. My !'s in square brackets. Merry Christmas, Big Blue. The internal system of the world's biggest computer company was disrupted for almost 72 hours by an electronic Christmas card. IBM's public relations department played down the seriousness of the incident, but according to our mole at IBM, "it crippled us". The computer equivalent of a nuclear meltdown [!] began at a university in West Germany when someone tapped into [!] IBM's Prof (PRofessional OFfice) System with a graphics-laden Christmas message. Whether it was deliberate or a coding error was not clear [!], but the card quickly became a hit and was passed on to various routing systems. As every computer buff knows, graphics use large bites of memory and this one gobbled up an ever expanding chunk of the Prof System as it multiplied its way through IBM offices. This was a week ago Friday, just before quitting time in Europe and during the first half of the workday on this side of the water. When the system goes down, IBM simply cannot work because just about everything is dependent on the [!] computer, right down to daily diaries with meeting schedules. By early Monday, the system in Canada was partly restored so that employees could tap into the data base to read files. But they couldn't use printers or communicate with other offices until the all-clear was sounded, which was after 10 am Eastern time. An IBM spokesman said the impact on operations varied from country to country. Police work to track down the culprit was turned over to Bitnet and Earn, a pair of computer networks that link universities in North America and Europe. The list of suspects has been narrowed to two at the Technical University of Clausthal, a small town south of Hanover. Forwarded by Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb ------------------------------ To: RISKS FORUM (Peter G. Neumann -- Coordinator) Cc: rpick@ucqais.uc.edu (Roger Pick), willis@rand-unix.ARPA Subject: Social Insecurity (Re: RISKS-5.82) Date: Thu, 24 Dec 87 09:12:05 PST From: willis@rand-unix.ARPA Let's talk about the SSN some more, even tho it's been done a lot. Originally the SSN was the number that identified one's account with the SSA; hence, it was like a bank account number. As we all know, the cards and literature from the SSA all specificically say: Not an identification number. In fact it was called the SSAN. As the SSN spread throughout society, someone along the way observed that it could play the role of a personal identifier. I do not recall, may not even ever have known, the first such occurrence. The best definitive treatment of the SSN and its role in society is chapter 16 of the report of the Privacy Protection Study Commission: Personal Privacy in an Information Society, July 1977, USGPO. I wrote the original drafts of the chapter, and at the time, it was factually complete and accurate. It is of course now 10 years old. Generally speaking, there are only a few situations in which one is obligated by law to give his SSN. Aside from the SSA business, it generally revolves around tax reporting and secondary aspects of same. Thus, financial transactions require the SSN but it's still really a tax matter because the IRS wants to track financial matters in its own interests. At least one state has required by law that the SSN be the driver license number and it was upheld in court; I think it was Virginia. Another state tried but was shot down in court; it may have been Illinois. UCLA tried to use it as a student ID but backed off when threatened by a student in a court case. The point is that most organizations that ask for it do not have a legal basis for requesting it. Rather, it's more like a condition of doing business with the organization. In that respect, it's like one's phone number or driver license, one or both of which are commonly asked for in California when making a bankcard purchase. On occasion, I have challenged such requests, usually successfully, but it's always a hassle because the clerks are only doing as told. The phone number is easy; give any one that comes to mind. That one has never backfired on me; I and a lot of other people give a business phone. After all why asdvertise a residential number that you pay to keep unlisted? I have corresponded with MasterCard about this, but it can do nothing to control the merchants. They do not require it of the merchants, and it's not clear to me why the merchant's even want the supplementary data. I suppose they believe that the driver license number may lead to a good current address and that a phone number may be useful in a collection action. I frankly feel uneasy about a phone number, a DL number, and a bankcard number on one piece of paper being handled by people who are not trained or accustomed to dealing with sensitive personal information. The combination of numbers makes it all that much easier to masquerade. Organizations try circuitous ways to get the SSN. For example, when one gets or renews a driver license in California, he finds a place for inserting the SSN but without explanation. The sheep among the population of course fill it in without asking although there is no statement on the form saying that it is required. The presence of the blank space for the SSN implies that it is a required data item. If one asks about it though (and clearly I have) he's told that "it's optional". How about that as a way to finesse people and get data that the state has no legal basis for requesting? It's clear why they want it; it makes it easier to correlate DMV data with that from insurance companies. Anyway, the best you can do is to ask anyone: Under what legal authority do you request my SSN? If there's no answer or a poor answer, then you're in the confrontation business -- which maybe you can win by escalating it up the line to the top of the organization. It's not unheard of for the administrative or ADP types to make a policy decision to use the SSN without the concurrence or knowledge of the top management. My usual line of argument is: "You have no legal basis for requesting my SSN and you have no need for it." If there is no legal basis for requesting it, your choices are: 1. Do business with another company, or at least, threaten to. 2. Continue to confront and ignore the requests as long as you can. Sometimes ignoring the request will make it go away. 3. Give an incorrect SSN number to satisfy the request, but realize that in doing so, there could always be a backlash if there happens to be a legitimate use for it. This amounts to seeding the recordkeeping system with noisy data. I think it's rather clear what's going on. The company you deal with has adopted the SSN as a convenient personal identifier. You might be able to force it to issue its own identifier. Sometimes an insurance company will contract with some outsider for record keeping support so the decision may have originated elsewhere. In the end, it's a Catch-22 situation. nne doesn't always have competition to give him alternate choices, or he may prefer the company that's bugging him. All any of us can do is drag our feet, refuse as often as possible, and bring pressure wherever possible. At the same time we need to know when we're legally obligated to give the SSN and what the penalty is for not doing so. That'a quick once-over lightly. One individual at Los Alamos contested a request for his SSN and as I recall, with success. I don't wish to intrude on his privacy by publishing his name/contact publicly. If you're interested in his case, I'll pass along names/addresses to him. Willis H. Ware, Rand Corporation ------------------------------ From: nuchat!sugar!peter@uunet.UU.NET (Peter da Silva) Date: 24 Dec 87 01:00:54 GMT To: comp-risks@uunet.UU.NET Subject: Expert systems (RISKS-5.78) Re: the folowing comment on the use of expert systems in environments where the system's decision making process can't be examined... For example, a pilot flying an aircraft through a fly-by-wire system can't examine all the control logic while flying the airplane. We can (and should) strive to give as much pertinent ... Perhaps we should avoid using poorly understood systems in real-time applications. It's debatable whether expert systems would actually buy you any efficiency in this case, but even ceding this point efficiency is not the only criterion in the design of control systems. Repeatability is at least as important. -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*. [Between Peter G. N. and Peter da S., this topic has been a real Repeter. But these sentiments are clearly a concern of the RISKS Forum. PGN] ------------------------------ Date: 24 Dec 87 12:15:00 PST (Thursday) Subject: Most-common passwords (RISKS-5.82) From: Rodney Hoffman To: RISKS@csl.sri.com In Security Interest Group Digest of 12 Nov 86, Bob Baldwin posted a list of likely passwords arranged by category. Though it doesn't say so, I believe the list is from college student accounts. The common categories were: Obscene words Favorite music (group names, albums) Ego strokes (lord, wizard, ...) Cartoon names and places Car names Insults to computer (farce, slave, ...) Female names Male names Funny words (whynot, foobar, simple, ...) Spy terms (secret, password, ...) Keyboard sequences (qweasd, poiqwe, ...) Tolkien characters and places Popular fiction and sci fi (characters, titles) esp. serials Doubled 3 letter groups (sexsex, foofoo, ... esp. user names doubled). Pet names (bowser, ...) Reversals (terces, drawkcab, ...) Composers Passwords for dead accounts (deadacct, unused, ...) Passwords based on host name for people with lots of passwords (e.g., for a system is named "cls": clspass, clspwd, ...) ------------------------------ Date: Fri, 20 Nov 87 11:58:41 EST From: decvax!osiris!phil@ucbvax.Berkeley.EDU (Philip Kos) To: decuac!KL.SRI.COM!RISKS, oster%dewey.soe.Berkeley.EDU@ucbvax.Berkeley.EDU Subject: Permissions and setuid on UNIX (Re: RISKS digest 5.57) I thought a reply to David's exhaustive explanation of the "correct" use of UNIX setuid to allow copying otherwise unreadable info (RISKS 5.57) was warranted. His description of setting up special groups to make the student's file readable by the setuid-teacher process is interesting, but as unnecessary as it is (admittedly) ungainly. > From: oster%dewey.soe.Berkeley.EDU@Berkeley.EDU (David Phillip Oster) > Subject: UNIX setuid stupidity > Date: 6 Nov 87 20:08:36 GMT > ... [the task] would copy a file owned by a student into a directory > owned by a teacher. ... The method David described will certainly work but is unnecessarily complicated. What is really needed is for the copy process to use its effective uid (teacher) to open the target file, and then use its real uid (student) to read the source file. open() uses the effective uid (not the real uid) which makes it possible to open the teacher's file, but not to open the students's file. However, the proper permission is needed only for the open(), and not for any read()s or write()s. This makes it possible to create the teacher's file *and* open the student's file for reading within the same process, by fiddling with the process' effective uid. (Aside: I recently debugged a problem with another local setuid process which was using the access() system call to determine whether or not a data file should be written. I have to wonder about the usefulness of access(), which uses the process' real uid to check permissions, when the real uid is virtually useless because of open()'s use of the (different) effective uid for the same purpose.) The scheme is to open() the teacher's file, then set effective uid to real uid, then open() the student's file and perform the copy. The basic copying procedure thus becomes more complicated, but any global mucking around with the system (like dynamically creating and removing a unique group id, or statically assigning unique group ids for each (teacher, student) pair at the beginning of a school term) is avoided. A simple implementation using /bin/cat to do the actual copying follows. This code works on a Pyramid running OSx version 4.0 (OSx is a "dual port" 4.2BSD and SysV.2 UNIces); it should work on any "real" UNIX system, using either setuid(getuid()) (as shown) or the appropriate combination of getreuid() and setreuid(). Extension to handle multiple files should be simple enough if it is necessary. ...!decvax!decuac!\ Phil Kos ...!uunet!mimsy!aplcen!osiris!phil The Johns Hopkins Hospital ...!allegra!/ Baltimore, MD [PLEASE CONTACT PHILIP DIRECTLY IF YOU WISH THE PROGRAM... PGN] ------------------------------ Date: Tue, 8 Dec 87 05:50:37 PST From: Michael S. Fischbein To: RISKS@KL.SRI.COM Subject: UNIX chroot and setuid (Re: RISKS-5.71) Organization: NASA Langley Research Center, Hampton, VA I must disagree with the conclusions drawn by the comment in RISKS 5.71 that chroot() will not prevent a setuid program from accessing the rest of the system. The scenario described will allow such access BUT proper design of a setuid() program designed for security will prevent this. The foundation of any classified data system is the `need to know.' Analogously, the foundation of a security conscious computer program must be that only sufficient permissions to do the required task are granted. If you only need to read the data in a file, you do not get write permission. For setuid()/chroot() programs, the user whose ID is being set to should NOT EVER be root. ROOT SETUID SHOULD ONLY BE USED IF ACTUAL ROOT PERMISSIONS ARE REQUIRED. If you are setting up a chroot() section of the tree, all required permissions could easily be satisfied by having a dummy user number to own all the system files, directories, etc in that section of the tree. Full protection could involve rewriting the system calls for open() to not allow root type access to programs linked with the system library in the restricted part of the tree. This step is not necessary; setuid() is a powerful tool that is easily toned down to the appropriate level by selecting an appropriate user id to set to. Don't use root unless it is necessary. In fact, the setuid() call itself is overused. Most programs that require the sort of permissions revisions that setuid() permits can get by with setgid(). mike Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization. [These last two messages have been backlogged for a while. I think they are of interest. However, it is important to note that there are many other vulnerabilities as well, and attempts to patch around or use carefully a particular vulnerability does not imply the absence of other problems. So please temper any future contributions accordingly. PGN] ------------------------------ End of RISKS-FORUM Digest ************************