Date: 11 Mar 1985 0010-MST (Monday) Subject: Security Mailing List, # 9 ---------------------------------------------------------------------------- Editor's corner The computer did it!! Not me!! I only program the thing!! He mistakenly bumped a counter when I wasn't looking and made the last list I sent out eight instead of seven. I'm so ashamed (of him, of course). His pay has been docked, and I hope it'll never happen again. ===> Issue 7 doesn't exist; A number was skipped. <============= Except for issue #5. Apparently ihnp4 ran out of tmp space the night #5 went out, and everyone with ihnp4 'tween me and thee lost out. I'm sending it out to the affected parties again tonight. Lots of fun, this job. Newcomers to the list since last issue: Russell L. Brand (brands@lll-crg) D. Byle (dbyle@pyrcorp) Marc Lesure (lesure@asuvax) R Novak (rnovak@pyrcorp) ---------------------------------------------------------------------------- Date: Wed, 30 Jan 85 19:40:58 nst From: Andrew Draskoy Subject: Why setgid is unsafe in pre-4.2bsd To see the problem, first consider how easy it is to create a file owned by yourself, but in a group that you don't normally have access to. Any setgid programme or shell script that creates file will do. If you can get access to a user's account who is in a group you want, you can create such a file. This can happen in any number of ways, as you are all aware. John Pierce's setuid shell script bug (posted in list #3) compounds the problem, especially since either a setuid or setgid script will potentially let you at a group. If that wasn't enough, we can look at all the bugs/features kindly given to us by folks at Berzerkly: Here is what a chown(2) call should look like: chown(path, owner, group) and guess what appears in 4.1bsd's ex3.7preserve (which is setuid root): chown(path, owner) Evidently someone forgot that chown(2) also changes the group. While they were at it, they forgot about lint. Thanks to the bsd C-compiler, this gets translated to chown(path, owner, 0) Voila! A file in group zero, owned by you. All you need to do is get your editor session preserved, which is easy enough. How many of you use group zero as a privileged "root" group? Now the crunch: Prior to 4.2bsd, you could set any mode you liked on any file that you owned. So how about setting the setgid bit on a file you created using one of the methods outlined above? A simple application of dd will let you put anything you like in the file, while leaving the group intact. Since you can change the modes at any time, the file can remain very inconpicuous for a long time. To detect files like this, you would really have to do regular find(1)s from / to look for files in groups that their owners are not in. This is of course, a pain. Now, this is not really a problem because it only occurs on systems with bugs and security leaks. On the off chance that this does not describe your system (:-), you may want to implement a fix. What we did was modify the chmod system call to not let anyone setgid a file who's group was different from the effective group of the process. This spoils the functionality of chmod(2) a bit, but most programmes will not need to do anything outside this restriction anyway. Andrew Draskoy {akgua,allegra,cbosgd,ihnp4,mcvax,utcsrgv}!garfield!andrew ---------------------------------------------------------------------------- From: denelcor!brl-bmd!ron@brl-tgr.arpa Date: Thu, 7 Mar 85 22:47:09 EST Original-From: Ron Natalie Subject: Process group bug This bug is fixed in 4.3 BSD and the BRL VAX UNIX rel 3. Of course, the fix causes subtle things to break like rlogin and some of the fancier shells. These were fixed for the most part as well. -Ron ---------------------------------------------------------------------------- Date: Thu, 7 Mar 85 15:35:52 pst From: hao!ucscc!root (00050000) Subject: Treatise on uucp needed I wish somebody would lay out how to set up a uucp system with all the permissions and passwd entries and everything. Ours presently runs wide open; i.e. all the files mode 666 and directories mode 777. If I change anything it breaks. ---------------------------------------------------------------------------- Subject: Re: Security Mail List, # 5 Date: 06 Mar 85 09:36:50 PST (Wed) From: David Barto {ucbvax|decvax|ihnp4}!sdcsvax!celerity!barto I seem to have missed #5 of this list, I have 4 and 6. As a side note, I would be interested if anyone else applied the fixes to the shells (sh/csh) which close the suid shell script problems. I have them in, and they work, preventing users from getting shells with 'root' or other privledges, beyond there own. Keep your users at bay, get the fix in! David Barto akgua!celerity!barto {decvax || ucbvax || ihnp4}!sdcsvax!celerity!barto "If you are using more than 10 sites to get here, you are taking the long way" ---------------------------------------------------------------------------- The UNIX security issues mail list Ignore the headers on this list and mail to: ...denelcor!security (mail for the list). ...denelcor!sec-request (administrativia).