Date: 13 Apr 1985 2031-MST (Saturday) Subject: Security Mailing List, # 13 ---------------------------------------------------------------------------- Newcomers to the list since last issue: Angel Casado (adrvax!angel@ihnp4) George (geo@brl-bmd) Howard (howard@brl-bmd) Karl A. Nyberg (karl@vrdxhq) Seth Zirin (megad!seth@sbcs) Mark Smith (mjs@uvacs) Gene Lege (ots!gene@rice) Marty Schoff (schoff@cadtroy) John McDermott (secure@unmvax) Sid Shapiro (ss@wanginst) Doug Tygar (tygar@harvard) ---------------------------------------------------------------------------- Date: Wed, 27 Mar 85 14:30:36 mst From: boulder!andy (Andrew M. Rudoff) Subject: Annoying Anomalies Here is a strangeness I have found with /bin/csh. This probably is not a "security problem", but it falls into the same catagory as the script while 1 mkdir x cd x end before quotas. Back when we were running 4.1, we had a "free" account which we had to remove because someone would always pull a stunt like the above script. True, it doesn't give one "root", but it caused a great deal of grief when the file system filled up. Now, under 4.2, I found another such annoying thing: first, notice that when you type eval \!! to csh, you get an infinite loop echoing "eval !!" to your screen. Now take that command and pipe it to "logout": eval \!! | logout What happens is the shell forks four or five subshells (executing the same commands!?!) and then logs out. You very quickly get a load average of about 30, and you cannot kill the shells because they do not stick around long enough! There is no parent to kill; it logged out first! When I first tried it, we had to reboot the machine. We then tried it on a Pyramid which could handle the load a lot better than a VAX, and found a way to stop it: Since every time the shell "logs out" it executes ~/.logout, just put something like "sleep 10000" in the .logout file, wait a few minutes, do a "ps x", and kill all of the processes doing "sleep 10000". Incidently, when you give the "eval..." command, you are logged out right away (so if you must test this, log back on SOON and fix up the .logout file). On the average VAX 11/780, it takes 5-10 minutes for the machine to become useless. There are a bunch of other strange things I have found with the csh, but they are definitely not security problems. Interested people can send me mail. Here is a strangeness I found with /bin/login. It requires that you know the passwd to some other login. We have plenty of logins with no passwd (who, sync, etc.) and it took me one guess to figure out the passwd for uucp. I will use uucp in my example: % sh # get into a subshell $ login uucp # (use /bin/login) Password: # guess! Shere # this is uucp saying "hello". wait for timeout. # if I did this with "who", I would just wait until # the "who" finished. % whoami # back to original shell andy # with original UID % who am i # but look at the utmp entry (could use "u", or "who") boulder!uucp ttyd0 Mar 27 13:09 Now I can send mail from "uucp", hide from question askers (it doesn't look like "andy" is logged in anymore)... I tried to use this against sendmail (uucp is a "trusted user") but I couldn't get anything interesting to happen. ___ Andrew M. Rudoff (andy@boulder) University of Colorado at Boulder {ucbvax!hplabs | allegra!nbires | decvax!kpno | harpo!seismo | ihnp4!kpno} !hao!boulder!andy ---------------------------------------------------------------------------- Date: 12 Apr 85 10:26:28 EST (Fri) From: Craig Partridge Subject: big 4.2 vm bug Here is a major 4.2 security hole we've now learned about from three different sources. It is particularly nasty since it doesn't require anything more than a knowledge of adb to exercise, and we have yet to get a satisfactory fix. My apologies to some people who have asked I not talk about this bug -- in quietly trying to find the fix, I have concluded that the bug is becoming known to more than just system administrators, and we need a proper fix. THE PROBLEM: The 4.2 virtual memory code allows you to share code even if the code has been altered by ptrace. (This bug appears in standard 4.2, and ULTRIX. It may exist on SUNs, I haven't had a chance to check. It is fixed in 4.3). A good way to illustrate the bug is: % adb su /* change the code to ignore the password check */ ^Z stopped % su Password: /* type anything */ # WHY IT HAPPENS: Apparently the ITEXT bit which is turned off when a text page is muddied isn't checked properly. But there is more to it than that. We put in code in xalloc() to refuse to share pages in which the ITEXT bit is turned off and it fixed the problem but caused a bad race condition. There is a second bug that has to be fixed to make this fix work, and none of the wizards here has been able to find the time to trace it. THE FIX: We ain't got it. The best we've seen is the one from dave@riacs, and it is appended below. But it forces you to be the owner of a binary to debug it -- a restriction we weren't happy with. People at Berkeley have suggested they have a correct fix, but never responded to requests to send it to us. If anyone has the "proper" fix, could you please distribute it? Thanks, Craig Partridge craig@bbn-loki (ARPA) craig%loki@csnet-relay (CSNET) {bbncca,ihnp4,wjh12}!bbncca!craig (USENET) ======================================================================= Below is he context diffs for a two line fix which eliminates this hole. As is typical, the line numbers will probably be off, but with the context, you should be able to repair the flaw. I added a little to the front of the old versions context to aid in the fixing. This is to be found in procxmt(), in /sys/sys/sys_process.c. *************** *** 136,146 /* write user I */ /* Must set up to allow writing */ case 4: /* * If text, must assure exclusive use */ if (xp = u.u_procp->p_textp) { if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX) goto error; xp->x_iptr->i_flag &= ~ITEXT; --- 141,148 ----- * If text, must assure exclusive use */ if (xp = u.u_procp->p_textp) { + if (u.u_uid && xp -> x_iptr -> i_uid != u.u_uid) + goto error; if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX) goto error; xp->x_iptr->i_flag &= ~ITEXT; ---------- ========================================================================== ---------------------------------------------------------------------------- Subject: a couple of questions Date: 13 Apr 85 09:15:30 MST (Sat) From: denelvx!lmc As long as everything is so quiet, I though I might ask a few questions: Are there any known security problems with honey-danber? Suppose I were running 4.2 fixed according to the articles that we have already seen here, with honey-danber and the new message handler (5); how secure is mail on such a system? Any better than before? Or is the primary problem with mail the ability to get superuser status itself? Lyle ---------------------------------------------------------------------------- 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).