roy@phri.UUCP (Roy Smith) (12/30/85)
Index: ucb/man.c 4.2BSD
ucb/Makefile 4.2BSD
Description: When you run "man x" and the cat file has to be made, it is
left with mode 0666, and owned by whoever happened to run man. This
was noticed one day when "man sh" produced neither output nor error
message. On investigation, it was found that /usr/man/cat1/sh.1 was
0 length; some curious person must have tried to do something like
"cat > /usr/man/cat1/sh.1"
Repeat-By:
rm /usr/man/cat1/sh.1
man sh
ls -l /usr/man/cat1/sh.1
Fix: Install the following 2-line patch. Also, change the Makefile so
man is installed set-uid. I'll leave it to other, smarter, brains
to figure out if this opens up any security loopholes.
*** /usr/src/ucb/man.c.old Sun Sep 25 21:05:27 1983
--- /usr/src/ucb/man.c Sun Dec 29 21:57:25 1985
***************
*** 256,263
fflush(stdout);
unlink(work2);
sprintf(cmdbuf,
! "%s %s > /tmp/man%d; trap '' 1 15; mv /tmp/man%d %s",
! NROFFCAT, work, getpid(), getpid(), work2);
if (system(cmdbuf)) {
printf(" aborted (sorry)\n");
remove();
--- 256,263 -----
fflush(stdout);
unlink(work2);
sprintf(cmdbuf,
! "%s %s > /tmp/man%d; trap '' 1 15;mv /tmp/man%d %s;chmod o-w %s;chown root %s",
! NROFFCAT, work, getpid(), getpid(), work2, work2, work2);
if (system(cmdbuf)) {
printf(" aborted (sorry)\n");
remove();
--
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016brian@scgvaxd.UUCP (Brian Zill) (01/01/86)
In article <2093@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >Index: ucb/man.c 4.2BSD > ucb/Makefile 4.2BSD > >Description: When you run "man x" and the cat file has to be made, it is > left with mode 0666, and owned by whoever happened to run man. This > >Fix: Install the following 2-line patch. Also, change the Makefile so > man is installed set-uid. I'll leave it to other, smarter, brains > to figure out if this opens up any security loopholes. Yes, this is a major security problem. man calls more to page the longer manual entries, and more has a shell escape... Ta Da! you're superuser! What we did at Harvey Mudd College where I go to school is to put some code in to set the effective uid and gid back to their real values after the fork that provides the shell escape in more. We have other priv'd programs there that use more as a pager and this seemed the simplest place to close this particular hole. (Yes, this also gets the "vi" escape). Probably more important than this is to realize that whenever possible, don't run things setuid when setgid will do. (We have our man run setgid to group man and have the /usr/spool/man/cat directories writable to that group. Also, system people are in group man so they can add new entries) That way, even if you do leave a security hole, you're not giving your entire system away. Making a program setuid without thinking carefully about is one of the two most common ways (in my limited experience) in which security holes get added to 4.2 (the other is having root programs write to world writeable dirs), too many holes come with the system as it is. Yours for securer systems everywhere, --Brian P.S. Anyone know what happened to the securiy mailing list? I haven't seen an issue in months and have some things to contribute. Here: {allegra,ihnp4,seismo}!scgvaxd!brian There: {allegra,ihnp4,seismo}!scgvaxd!muddcs!brian
jsdy@hadron.UUCP (Joseph S. D. Yao) (01/03/86)
In article <503@scgvaxd.UUCP> brian@scgvaxd.UUCP (Brian Zill) writes: >In article <2093@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >>Index: ucb/man.c 4.2BSD >> ucb/Makefile 4.2BSD >>Description: When you run "man x" and the cat file has to be made, it is >> left with mode 0666, and owned by whoever happened to run man. >>Fix: Install the following 2-line patch. Also, change the Makefile so >> man is installed set-uid. I'll leave it to other, smarter, brains >> to figure out if this opens up any security loopholes. > >Yes, this is a major security problem. man calls more to page the longer >manual entries, and more has a shell escape... Ta Da! you're superuser! This is n o t to re-open the discussion, but merely to note that I still feel that the best thing to do is to have as few things as possible owned by root and setuid to root. Best is to have these things owned by user 'man' (well, 'bin' if you have to, but I don't like it!). That way the worst a user can do is to munge the man pages (or everything owned by 'bin' which is why I don't like the latter). Better, of course, to a l s o set back to real uid if you can for every shell escape: >What we did at Harvey Mudd College where I go to school is to put some >code in to set the effective uid and gid back to their real values after >the fork that provides the shell escape in more. Also better to try to write code that checks permissions for each step along the way (and, yes, sometimes re-invent the wheel). -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}