13 May
2017
13 May
'17
5:30 a.m.
From: Clem Cole
I said -- profil - I intended to say ptrace(2)
Is that the one where running an SUID program under the debugger allowed one
to patch the in-core image of said program?
If so, I have a story, and a puzzle, about that.
A couple of us, including Jim Gettys (later of X-windows fame) were on out way
out to dinner one evening (I don't recall when, alas, but I didn't meet him
until '80 or so), and he mentioned this horrible Unix security bug that had
just been found. All he would tell me about it (IIRC) was that it involved
ptrace.
So, over dinner (without the source) I figured out what it had to be:
patching SUID programs. So I asked him if that was what it was, and I don't
recall his exact answer, but I vaguely recall he hemmed and hawed in a way
that let me know I'd worked it out.
So when we got back from dinner, I looked at the source to our system to see
if I was right, and.... it had already been fixed! Here's the code:
if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
goto error;
Now, we'd been running that system since '77 (when I joined CSR), without any
changes to that part of the OS, so I'm pretty sure this fix pre-dates your
story?
So when I saw your email about this, I wondered 'did that bug get fixed at
MIT when some undergrad used it to break in' (I _think_ ca. '77 is when they
switched from an OS called Delphi on the -11/45 used for the undergrad CS
programming course - I _think_ they switched that machine from Delphi to
Unix), or did it come with PWB1? (Like I said, that system was mostly PWB1.)
So I just looked in the PWB1 sources, and... there it is, the _exact_ same
fix. So we must have got it from PWB1.
So now the question is: did the PWB guys find and fix this, and forget to
tell the research guys? Or did they tell them, and the research guys blew
them off? Or what?
Noel
13 May
13 May
5:38 a.m.
New subject: The evolution of Unix facilities and architecture
On Fri, 12 May 2017, Noel Chiappa wrote:
So when we got back from dinner, I looked at the
source to our system to see
if I was right, and.... it had already been fixed! Here's the code:
if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
goto error;
Err, isn't that the sticky bit, not the setuid bit?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
5:52 a.m.
New subject: The evolution of Unix facilities and architecture
On Fri, May 12, 2017, at 19:38, Dave Horsfall wrote:
On Fri, 12 May 2017, Noel Chiappa wrote:
The sticky bit makes it keep the image in memory when there are no
processes using it. I assume x_count is determining whether there are
processes using it. So, taken together, these checks are "is there or
might there be in the future a process, other than the one being
debugged, using this exact copy of the image rather than loading it from
the disk".
The next line is "xp->x_iptr->i_flag &= ~ITEXT", which I assume
prevents
the image from being reused for other processes started while this one
is running.
I am looking at 7th edition in the UnixTree site, the whole fix is:
/*
* 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;
}
The equivalent section to the one this appears in in 6th edition doesn't
have the fix, and the comment claims, doesn't work at all:
/* write user I (for now, always an error) */
case 4:
if (suiword(ipc.ip_addr, 0) < 0)
goto error;
suiword(ipc.ip_addr, ipc.ip_data);
break;
This is clearly PDP-11 specific, maybe a similar bug reappeared with
demand-paged virtual memory.
So when we got back from dinner, I looked at the
source to our system to see
if I was right, and.... it had already been fixed! Here's the code:
if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
goto error;
Err, isn't that the sticky bit, not the setuid bit?
6:26 a.m.
New subject: The evolution of Unix facilities and architecture
On Fri, 12 May 2017, Random832 wrote:
The sticky bit makes it keep the image in memory when there are no
processes using it. I assume x_count is determining whether there are
processes using it. So, taken together, these checks are "is there or
might there be in the future a process, other than the one being
debugged, using this exact copy of the image rather than loading it from
the disk".
I know that, but the discussion was about the SUID bit, and the ability to
modify the in-core image of a set-uid program being run...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
if (xp->x_count!=1 ||
xp->x_iptr->i_mode&ISVTX)
goto error;
Err, isn't that the sticky bit, not the setuid bit?
6:48 a.m.
New subject: The evolution of Unix facilities and architecture
On Fri, May 12, 2017, at 20:26, Dave Horsfall wrote:
On Fri, 12 May 2017, Random832 wrote:
The sticky bit makes it keep the image in memory when there are no
processes using it. I assume x_count is determining whether there are
processes using it. So, taken together, these checks are "is there or
might there be in the future a process, other than the one being
debugged, using this exact copy of the image rather than loading it from
the disk".
I know that, but the discussion was about the SUID bit, and the ability
to
modify the in-core image of a set-uid program being run...
It seems to me that this check is central to being able to (or not)
modify the in-core image of any process at all other than the one being
traced (say, by attaching to a SUID program that has already dropped
privileges, and making changes that will affect the next time it is
run).
if (xp->x_count!=1 ||
xp->x_iptr->i_mode&ISVTX)
goto error;
Err, isn't that the sticky bit, not the setuid bit? 
6:22 a.m.
New subject: The evolution of Unix facilities and architecture
Interesting... I don't remember Gettys being at the meeting (I would get
to know Jim a few years later when he was at Princeton before he came back
to MIT to work on X) and he's a been a friend of mine for a number of years
(actually lives in the next town over).
I do not remember all the details of the bug at this point, to many beers
ago; but yes the jist of the issue was being able to write to user memory
with ptraced process with SUID being involved.
The only thing that worries me about your response is I thought remembered
that MMU was somehow involved. Just turning off SUID was not the only
part of the solution.
I do remember that the bug was in the Research kernel at the time and
Dennis had not known about it until that meeting so if PWB had it fixed,
that's an example of something that did not go back, which I would find
surprising.
I suspect MIT found and fixed it independently, but it never got passed it
back for whatever reason.
We should try to look in the PWB 1.0 kernel.
Clem
On Fri, May 12, 2017 at 7:30 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
From: Clem
Cole
I said -- profil - I intended to say ptrace(2)
Is that the one where running an SUID program under the debugger allowed
one
to patch the in-core image of said program?
If so, I have a story, and a puzzle, about that.
A couple of us, including Jim Gettys (later of X-windows fame) were on out
way
out to dinner one evening (I don't recall when, alas, but I didn't meet him
until '80 or so), and he mentioned this horrible Unix security bug that had
just been found. All he would tell me about it (IIRC) was that it involved
ptrace.
So, over dinner (without the source) I figured out what it had to be:
patching SUID programs. So I asked him if that was what it was, and I don't
recall his exact answer, but I vaguely recall he hemmed and hawed in a way
that let me know I'd worked it out.
So when we got back from dinner, I looked at the source to our system to
see
if I was right, and.... it had already been fixed! Here's the code:
if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
goto error;
Now, we'd been running that system since '77 (when I joined CSR), without
any
changes to that part of the OS, so I'm pretty sure this fix pre-dates your
story?
So when I saw your email about this, I wondered 'did that bug get fixed at
MIT when some undergrad used it to break in' (I _think_ ca. '77 is when
they
switched from an OS called Delphi on the -11/45 used for the undergrad CS
programming course - I _think_ they switched that machine from Delphi to
Unix), or did it come with PWB1? (Like I said, that system was mostly
PWB1.)
So I just looked in the PWB1 sources, and... there it is, the _exact_ same
fix. So we must have got it from PWB1.
So now the question is: did the PWB guys find and fix this, and forget to
tell the research guys? Or did they tell them, and the research guys blew
them off? Or what?
Noel
2780
days inactive
2781
days old
6 comments
4 participants
participants (4)
-
Clem Cole -
Dave Horsfall -
jnc＠mercury.lcs.mit.edu -
Random832