From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12957 invoked from network); 21 Nov 2021 02:08:21 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2021 02:08:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 213EC94486; Sun, 21 Nov 2021 12:08:18 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E181393D61; Sun, 21 Nov 2021 12:05:33 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 6050193D61; Sun, 21 Nov 2021 12:05:31 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id A66DF93D5E for ; Sun, 21 Nov 2021 12:05:30 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 54B5635E32F; Sat, 20 Nov 2021 18:05:30 -0800 (PST) Date: Sat, 20 Nov 2021 18:05:30 -0800 From: Larry McVoy To: Rob Pike Message-ID: <20211121020530.GO15051@mcvoy.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [TUHS] Two anecdotes X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" It was early days. People have to spin up, I can't tell you how many times other people got it and I got it later. On Sat, Nov 20, 2021 at 11:54:59AM +1100, Rob Pike wrote: > Clever though those anecdotes may be, it was much easier to become > root. Sometime around 1981, I was visiting USG and they were in a bit > of a panic, checking that their system was intact. Why? Because early > that morning, there was a phone call to the machine room: >=20 > "Hi, this is Ken. What's the root password?" >=20 > The call was successful. >=20 > Any sysadmin worth his paycheck would have known that Ken isn't awake > in the mornings and could have blocked this interloper. But... >=20 > -rob >=20 > On Sat, Nov 20, 2021 at 9:45 AM Alan Glasser wrot= e: > > > > Here are two anecdotes that Doug suggested I share with TUHS (I am new = to TUHS, having joined just last month). > > > > First: > > > > The creation of access(2). > > [Marc Rochkind documented a version of this on page 56 of his book Adva= nced Unix Programming (1985, First Edition) discussing link(2). The footno= te on that page says "Alan L. Glasser and I used this scheme to break into = Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] > > > > Doug pointed out that the timing was probably later, as access(2) was n= ot in the Sixth Edition release, but probably right after the release (afte= r May 1975?). > > > > It arose from a discussion I was having with Marc, with whom I worked o= n SCCS and other PWB tools. We were discussing some mechanism that would re= quire moving directories (actually, simple renaming) in a shell procedure. = I told Marc that only root could make links to directories or unlink direct= ories, but he told me that he has renamed directories with the mv command. = I said then mv must be setuid to root, so we looked, and, of course, it was= =2E I then looked at the source code for mv and quickly saw that there was= no attempt to check permission on the real uid. So I told Marc it would al= low anyone to become root. He wanted to see it in action, so I logged into = research (I don???t remember what our organization's shared login was). No= one in our organization had root access on research. Marc and I didn't ha= ve root access on our organization's machines; Dick Haight et. al. didn't s= hare that privilege (Dick was the manager of the super-users). I think th= e actual sequence of commands was: > > cd / > > cp etc/passwd tmp > > ed tmp/passwd > > 1s/^root:[^:]*:/root::/ > > w > > q > > mv etc etc2 > > mv tmp etc > > su > > mv etc tmp > > mv etc2 etc > > mv etc/as2 etc/.as2 > > {logout, hangup and wonder} > > The last bit was a test to see what was noticed about what I did. > > Marc and I talked for a while about it and discussed if we had any need= to be root on our local machines, but couldn't think of any pressing need,= but knowing we could was a bit of a comfort. After a short time, Marc sug= gested logging back in to see what, if anything, had been done. > > /bin/mv had lost setuid to root > > /etc/as2 was restored > > /etc/.as2 was nonexistent > > > > And the next day, the motd on research mentioned that there's a new sys= call: access. And mv(1) now used it. > > > > Second: > > > > Our organization was one (out of possibly others) subject of Ken's code= nih that he documented in his Turing Award article in CACM. > > > > As previously described, root access was closely guarded in the PWB org= anization and, according to Doug, freely available in research. Ken had gi= ven us a login that was shared by PWB development and we had given Ken a lo= gin to our systems. We had no root access on research and Ken had no root a= ccess on our systems. > > > > Our C compiler guy, Rich Graveman, who kept in close contact with Denni= s and was always getting us the latest compiler to install, had gone to MH = and came back with a tape of a new compiler. Rich, being a careful fellow,= did a size on c0, c1, c2 on the files from the tape and did the same on th= e running compiler pieces in /lib. > > Lo and behold, he discovered that the new compiler from Dennis was smal= ler than the old compiler even though it had a whole new feature (I think i= t was union). So Rich did nm's on the two different c0's and discovered a = name "codenih" in the old compiler that wasn't in the new one from Dennis. = He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, foll= owed by a cd codenih. Was he surprised! Then he went back to a local mach= ine and tried to login as root/codenih, which, of course, worked. He was e= ven more surprised and told a number of colleagues, myself included. (I lo= gged into research and printed out the source in /usr/ken/codenih. I was s= uper impressed.) > > > > I think you misunderstood the codenih bit. > > As Ken had given us a (shared among a few of us) login, we had given hi= m one. > > And Dick Haight refused him root access. > > And no one in PY had root access on research. > > > > So much for denying Ken root access on the PWB systems. > > Ken "infected" the PWB C compiler with codenih, which gave him free rei= n. I don't know how or when he first installed it, but I suspect he was aw= are of any extant security holes (e.g., the mv setuid root) to allow him to= replace the compiler the first time. > > > > I don't know if the PWB crowd was the impetus for Ken writing codenih o= r if it was something he had used on others prior to us or if he ever used = it on anyone else. > > Needless to say, Dick Haight was beside himself. > > I just thought it was a great feat of programming and was thrilled when= he described it in CACM. > > > > Alan > > > > > > --=20 --- Larry McVoy lm at mcvoy.com http://www.mcvoy.c= om/lm=20