Re: [TUHS] Two anecdotes

[Larry McVoy <lm@mcvoy.com>]

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:
> 
> "Hi, this is Ken. What's the root password?"
> 
> The call was successful.
> 
> Any sysadmin worth his paycheck would have known that Ken isn't awake
> in the mornings and could have blocked this interloper. But...
> 
> -rob
> 
> On Sat, Nov 20, 2021 at 9:45 AM Alan Glasser <alanglasser@gmail.com> wrote:
> >
> > 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 Advanced Unix Programming (1985, First Edition) discussing link(2).  The footnote 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 not in the Sixth Edition release, but probably right after the release (after May 1975?).
> >
> > It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, 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.  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 allow 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 have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users).   I think the 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 suggested 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 syscall: access.  And mv(1) now used it.
> >
> > Second:
> >
> > Our organization was one (out of possibly others) subject of Ken's codenih that he documented in his Turing Award article in CACM.
> >
> > As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research.  Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems.
> >
> > Our C compiler guy, Rich Graveman, who kept in close contact with Dennis 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 the running compiler pieces in /lib.
> > Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it 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, followed by a cd codenih.  Was he surprised!  Then he went back to a local machine and tried to login as root/codenih, which, of course, worked.  He was even more surprised and told a number of colleagues, myself included.  (I logged into research and printed out the source in /usr/ken/codenih.  I was super impressed.)
> >
> > I think you misunderstood the codenih bit.
> > As Ken had given us a (shared among a few of us) login, we had given him 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 rein.  I don't know how or when he first installed it, but I suspect he was aware 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 or 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
> >
> >
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm