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:<RISKS>, 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) <RISKS@kl.sri.com>
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 <Hoffman.es@Xerox.COM>
To: RISKS@csl.sri.com
In Security Interest Group Digest of 12 Nov 86, Bob Baldwin
<baldwin@xx.lcs.mit.edu> 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 <msf@ames-nas.arpa>
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
************************