dmmartindale (12/27/82)
The particular program posted may not be able to reliably read passwords if the terminal is placed into cbreak or raw mode, but I'll bet that I could write one that did, particularly if the person was a slow typist. If passwords is all you want, it might be a better attack to scan for instances of "login" which are cpu-bound, and take a copy of their password buffer while they are busily encrypting the supplied password to check it against the /etc/passwd field - this takes 1 or 2 seconds. Allowing general read on memory that may contain all sorts of data, such as the clists or buffers or user memory, is inherently vulnerable to this sort of snooping. Maybe having a special version of the kmem driver which allows access only to selected parts of the system (e.g. CPU and I/O statistics, perhaps proc table) is a partial solution, but some programs are going to have to be setuid or setgid because they need access to a process's stack in order to print arg lists (ps, w). So far we haven't worried too much about this at Waterloo since the people here who are skilled enough to write programs to extract this sort of information from the memory special files seem to be fairly reasonable, responsible people. But when someone on the net posts such a program for any turkey to compile and try, I guess we'll have to do something about it. Sigh. Dave Martindale
MCB@Mit-Mc (12/28/82)
From: Michael A Bloom <MCB@Mit-Mc> Date: 18 December 1982 08:00-EST While it is true that protecting kmem would be a solution to the security problem demonstrated by the raw queue monitoring program, I don't think it is a good one. An awful lot of programs are written by people who dont have root access that obtain information by reading kmem. Chances are that they might not have been written without free read access to kmem. Unfortunately, there are programs that make people "collectors" as well. Rehmi intimates a partial solution, although he did not come right out and say it: modify getpass() so that it sets raw input mode when it turns echo off. According to what he says, you wont be able to get reliable data from reading the input queue then... Or perhaps modify the memory driver so that certain areas were inaccessible. Or maybe break up kmem into two or more files, each of which can have separate protections. Then there are sites that dont have the "get number of chars to be read" ioctl. The only alternate way I know of to test for pending input is to seek to the raw clist for your terminal and read the character count field. There are many applications where knowing the number of characters that are available to read is of great importance. One of these, for example, is the "incremental redisplay" of many text editors including Emacs. I dont think protecting kmem is the right idea. Now that UNIX is becoming so commercialized, and Bell is developing a UNIX Validation Suite to test UNIX implementations against, there may be the tendency for large companies new to the UNIX field to want "secure systems". Let them have their secure systems, if neccessary, but lets at least put some thinking into how UNIX is made secure. Remember, kmem was _designed_ to be readable. Bell is going to be a lot stricter than it has been on what is called UNIX and what is not. It could turn out that the open, easy to program in environments that we call UNIX now wont fit the Bell model of UNIX ten years from now if it stems from changes that arose out of panic over security. ( Besides which, security breaches seem to occur more on the less comfortable to use, less open systems. For example, at Cal. State Northridge, we have had absolutely no security problems on our UNIX system, yet we have had a myriad of problems with our systems that run RSTS. Despite having gone to jail for computer crimes, a local high school kid is still breaking in to the system and damaging the file system or doing more serious mischief. The dec operating system seem to attract these types like flies, yet they have caused us no problems on UNIX. This is, I believe, because the people who cause security problems do so for the challenge mostly (There are a lot more in this class than the computer embezzlers, etc) and really dont care to on systems that allow freedom without requiring privilege. )
ka (12/29/82)
Michael Bloom's suggestion that getpass should set raw mode to prevent users from pulling passwords out of the input queue won't work; it just means that whoever wants to read the password has to pull it out of the address space of the program invoking getpass. That is more difficult, but as Michael points out, many people who try to break security do so for the challenge. In many environments the best approach to security is to trust your users and limit your efforts to keeping unauthorized users out, but sometimes that is not possible. As delivered, System V (and, I believe, System III) have /dev/mem pro- tected. Kenneth Almquist
ron@Brl (12/29/82)
From: Ron Natalie <ron@Brl> Date: 22 Dec 82 6:28:56-EST (Wed) Panic about security...certainly not. You might as well get rid of inode access bits too, if you care about PRIVACY at all. There is a lot of user sensitive data floating around in there (not nearly as bad now that buffers are usually out of kernel space, but people who have kmem readable probably have the disk devices and /dev/mem readable also). We've had kmem, mem, and the disk devices protected for years, and have never suffered any serious problems. Programs who really want to know (ps, mount, etc...) run setuid to root with appropriate restrictions. Due to the large amount of disk and system reconfiguration here, we wanted to make all system utilities independant of knowing about the namelist on /unix (it may be out of date because we do not necessarily boot the disk that the running root is on) and due to the kmem protection we have another minor device code on mem that is a generally readable structure of important user informaton such as the revision number, number of procs, major/minor device code of swapdev, plus the metering information...This allows users to get kernel entries in a user mode process without the ramifications of leaving kmem readable. Also note that indescriminate reading of kmem can screw up stuff if the user lets loose on the IO page by mistake. -Ron
Michael.Young.CMU-CS-A@SRI-UNIX (12/29/82)
From: Michael Wayne Young <Michael.Young.CMU-CS-A@SRI-UNIX>
Date: 23 December 1982 0112-EST (Thursday)
Yes, I think /dev/kmem was meant to be readable, but only by root.
Not only do you get i/o queues, but anything the kernel might ever
consider privileged information -- including user text/data spaces.
If you want to let non-root users read /dev/kmem (or /dev/mem, or even
raw devices, but that's another matter), you can easily let a
"privileged" group own them, let the group members read them, and
make any of that list of programs be setgid. [This reduces to trusting
this "privileged" group to not giving away their privileges, but
I find that much more reasonable. It has worked on the systems I've
run, and here at CMU, where I am not privileged, but don't miss it all
that much.] Note that you also have less setuid-root programs that
might break.
As an aside, I think that a careful system administrator can make
a Unix system much more secure than RSTS, or the myriad of
other Dec operating systems, because of the more coherent design
of Unix privileges. [Not perfect -- there are lots of ways to
easily screw up -- it's just easier to spot bugs and fix them fast.]
Also, I think that Unix is no more immune to malicious users than other systems.
>From my experience, troublesome users are fairly evenly distributed
among the available resources.
Wishing we'd all think more seriously about security (myself included),
Michaelobrien@Rand-Unix (12/30/82)
Date: Tuesday, 28 Dec 1982 09:56-PST At Harvard, according to Bruce Borden, they got around the problem by installing a "table" system call. I can't think of a single program that really wants to look at kernel memory for more than just a table of something-or-other, such as the file table, inode table, proc table, coremap table, etc. We installed one here under V6 UNIX and were quite happy. Table takes two arguments: an index for what table to grab, and an address in user space to put the table. If the second arg is NULL, the call stuffs nothing, but returns as a value the length of the table, so the user process can allocate memory for it. Works quite well, and much neater than looking up symbols in /frobunix. A header file ties index numbers to symbolic table names. Once it's set up it doesn't matter what you do to the kernel, or where the running version of UNIX is in the file system: tables stay tied to their indices. The only time you have to change the call is when you install a whole new kernel table that some user process has to look at. It should be pretty obvious that the required change in such a case is trivial.
Michael.Young.CMU-CS-A@SRI-UNIX (02/28/83)
From: Michael Wayne Young <Michael.Young.CMU-CS-A@SRI-UNIX> Date: 31 December 1982 0449-EST (Friday) I agree with yor suggestion for a 'table' call... I'd even be in favour of one that lets root processes write entries, somewhat like a POKE. [In fact, this whole idea reminds me of the TOPS-10 GETTAB and POKE calls. There youu use GETTAB to get a particular table entry, and POKE to change one (with the restriction that you specify before and after contents of a POKEd word, so you don't goof up, or nothing else POKEs in between).] I really prefer this kind of controlled (in comparison to looking up in a namelist) access to kernel structures for things like re-nicing, and various other fiddling (such as the "su" controversy discussed here long ago). Plus, it might make a 'ps'-like program almost readable (the code, that is). Access to the kernel via /dev/whatever is really a pretty silly idea the way it's used now. Michael