Date: Tue Oct 1 13:47:42 PDT 1991 Subject: Core Security Digest V1 #21 Core Security Digest Volume 1 Issue 21 subject(s): Re: Core Security Digest V1 #20 Re: one for the inner core divide by zero hole Re(2496): ^^^^^ div gives root access The unix core security mailing list is by invitation only and contains sensitive material which SHOULD NOT BE REVEALED to non-members. DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. If you must keep copies on-line, please encrypt them at the very least. PLEASE POST TO: core@uninet.cpd.com PLEASE SEND EMERGENCY ALERTS TO: core-emergency@uninet.cpd.com PLEASE SEND REQUESTS TO: core-request@uninet.cpd.com ------------------------------------------------------------------------ Date: Fri, 13 Sep 91 11:05:16 -0500 From: "David A. Curry" Subject: Re: Core Security Digest V1 #20 The following patch seems to fix the rdist problem, without causing any other problems, at least in my testing. The patch appears to be the same on all the systems we have sources for here: Sun-2 SunOS 4.0.3 Sun-3 SunOS 4.1.1 Sun-4 SunOS 4.1.1 Vax 4.3BSD (pre-Tahoe) Gould (Encore) 9080 UTX/32 2.0 Gould (Encore) NP-1 UTX/32 3.1A.7 CCI PowerNode 6/32 4.3BSD Tahoe Basically, as per Brad's argument, there is no real need to run as root while performing the chown/chmod in chog(). - If you're running as root, you can do whatever you want, so there's no need to setuid yourself anyway. - If you're not running as root, then you shouldn't be allowed to chown things you don't own, or chown them to people other than yourself, so there's no need for the setuid. - If you're not running as root, then you shouldn't be allowed to chmod or chgrp things you don't own, but the syscalls will let you do so for things you own, so again there's no need for the setuid. So, the solution is to just rip out the two calls to setreuid() around the chown/chmod in chog() in server.c - they aren't needed for anything. The diffs below are for SunOS 4.1.1; your line numbers may vary. The lines of code seem to be the same in all the versions listed above, though. *** /tmp/,RCSt1a08241 Fri Sep 13 10:44:28 1991 --- server.c Fri Sep 13 09:01:10 1991 *************** *** 1040,1047 gid = -1; } ok: - if (userid) - setreuid(userid, 0); if (chown(file, uid, gid) < 0 || (mode & 07000) && chmod(file, mode) < 0) { note("%s: chown or chmod failed: file %s: %s", --- 1040,1045 ----- gid = -1; } ok: if (chown(file, uid, gid) < 0 || (mode & 07000) && chmod(file, mode) < 0) { note("%s: chown or chmod failed: file %s: %s", *************** *** 1047,1054 note("%s: chown or chmod failed: file %s: %s", host, file, sys_errlist[errno]); } - if (userid) - setreuid(0, userid); return(0); } --- 1045,1050 ----- note("%s: chown or chmod failed: file %s: %s", host, file, sys_errlist[errno]); } return(0); } ------------------------------------------------------------------------ Date: Fri, 13 Sep 91 09:50:26 EDT From: kannan@oar.net Subject: Re: one for the inner core A quick and dirty fix is to disable rdist execute permissions for the world, and set it as... - -rwsr-x--- 1 root bin 727816 May 23 10:57 /usr/ucb/rdist PS: We noticed that this bug is manifest on the cray, running unicos 6.0 too. Cray has been made aware of this problem. ------------------------------------------------------------------------ Date: Thu, 19 Sep 91 23:41:11 -0700 From: shipley@kizmiaz.tcs.com Subject: divide by zero hole I am not sure if this is appropriate for this list PS: who is on this list? ------- Forwarded bbs Message current guesses from the b community: [ computer ] Message 2502 (1 left): Thu Sept 19, 1991 4:29pm From: (dlong) Subject: Re(2496): ^^^^^ 4 lines (?) The bug is in the kernel, not a library. My guess is that divide by zero is allowed and gives you 0, the uid of root. [ computer ] Message 2503 (0 left): Thu Sept 19, 1991 4:50pm From: (dlong) Subject: div gives root access 7 lines (?) I disassembled crt.o, and it looks like the fix was to add a call to suword instead of a direct store for the remainder. Apparently you could write to kernel memory otherwise. I'm not sure how you could exploit this though. Some system call must use _ip_div or _ip_udiv with a user-provided address. ------------------------------------------------------------------------ End of Core Security Digest Volume 1 Issue 21 **********************