19 Nov
2021
19 Nov
'21
10:41 p.m.
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
20 Nov
20 Nov
12:54 a.m.
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(a)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
1:30 a.m.
My recollection from the 70s is that the default root password on
all UNIX systems was "foo" and almost nobody ever changed it.
2:08 a.m.
Most of the hundreds (thousands?) of Unix systems running in Bell Labs seemed to have well
guarded root passwords. There was always social engineering, like Rob mentioned. And, of
course, setuid root exploits that I enjoyed.
Another anectdote:
Sometime around 1975 the NSA became a proud owner of a Unix system. They rewrote a whole
bunch. And invited Ken to visit. He surreptitiously observed someone logging into the
console as root. A bit later, they asked him to have a seat and try to break in. He sat
down and logged in as root. Apparently he was very good at observing keystrokes. He had to
explain himself. I wonder if they would’ve let him leave otherwise.
- Alan
On Nov 19, 2021, at 8:32 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
My recollection from the 70s is that the default root password on
all UNIX systems was "foo" and almost nobody ever changed it.
2:48 a.m.
On Fri, Nov 19, 2021 at 09:08:49PM -0500, Alan Glasser wrote:
Most of the hundreds (thousands?) of Unix systems
running in Bell
Labs seemed to have well guarded root passwords. There was always
social engineering, like Rob mentioned. And, of course, setuid root
exploits that I enjoyed.
Does anyone remember the security vulnerability existed where
/bin/mail was setuid root, and you could issue the command "!/bin/ed
/etc/passwd" and the editor would be executed as root because
/bin/mail failed to drop the setuid root privs before executing the
shell escape?
When I was a Freshman at MIT I implementing some image processing
programming on an old Unix system for a Materials Science professor in
1987 as part of MIT's Undergraduate Research Opportunities Program
(UROP). It was some ancient Unix program, and to my amazement, the
/bin/mail security vulnerability was there even though it was a famous
security oopise that should have been patched long before. I *think*
the system was some kind of AT&T Unix (not BSD) system, but I can't
remember the hardware or the specific Unix that was on the system.
Does anyone know how long and on which Unix variants this particular
/bin/mail setuid root vulnerability was around?
- Ted
3:08 a.m.
On Fri, Nov 19, 2021 at 9:11 PM Alan Glasser <alanglasser(a)gmail.com> wrote:
There was always social engineering, like Rob
mentioned
Me, after a pentesting company had given $EMPLOYER their shpiel: "And do
you use social engineering?"
"No, we never do that."
"Whyever not?"
"Because it *always* works, so we don't learn anything."
10:12 a.m.
Hi,
Alan wrote:
Apparently [Ken] was very good at observing
keystrokes.
A couple of decades ago, back when I used to work in offices with other
people, I got quite proficient at ‘reading’ their typing when viewing
the keyboard upside down, i.e. I was the other side of their desk.
It's not too hard if they're typing natural-language words and phrases
with the odd digit tacked on especially if one doesn't focus on each
individual keystroke but the pattern of presses. And it's easy to
practice on lots of typing where security isn't important.
--
Cheers, Ralph.
21 Nov
21 Nov
2:05 a.m.
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(a)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
894
days inactive
896
days old
7 comments
7 participants
participants (7)
-
Alan Glasser -
John Cowan -
Jon Steinhart -
Larry McVoy -
Ralph Corderoy -
Rob Pike -
Theodore Y. Ts'o