BSD tty security, part 4: What You Can Look Forward To

[Karl Denninger]

In article <26844:May100:59:2591 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>Let me be more explicit. I consider vendors to have a legitimate
>interest by default. I probably should have said just vendors, but there
>are organizations like CERT that I consider to have a legitimate
>interest but that aren't vendors. There are also individuals who can and
>have convinced me that they should see the code, for various reasons.

You have spoken with vendors about this in the past however, no?  I believe
there was a reference in your earlier posting about this (and how Sun wasn't
interested in it).

>I do not consider someone to have a legitimate interest in
>security-breaking code merely by virtue of being a system administrator.
>If I did, then I should be sending the code to practically everyone---
>there's no fine line between the manager of a major site and the
>``manager'' of a personal workstation. And that is an unacceptable risk.

I disagree.  But that's ok -- I have figured out most (I think) of what
you're alluding to.  And I think I have a fix -- actually, two different
fixes, both of which should be easily implemented.  Both ARE implemented on
two different machines from different manufacturers here.

Now all I have to do is find source code I can hack on to implement one of
these for our Sun systems, and I'm set.

>> 2)	The good guys, on the other hand, have to hunt around looking for
>> 	the problems and devise proof for the "bean counters" before we can
>> 	get any time allocated to work on a REAL fix.
>
>Sorry if you don't consider the detailed fixes I've posted to be a REAL
>fix. I'd love to hear from anyone who can propose a simpler set of fixes
>that can still be proven to work.

Ok, how about this:

1)	PTYs are either:
	a) Allocated dynamically, and have NO entry in /dev to try to pick
	   at.  (this is how the RS/6000 does it).  The entire slave side is
	   one /dev node, and the system knows which is which internally.
	   This is undesirable for a couple of reasons, not the least of
	   which is that write(1) to a pty probably won't work.

	b) Allocated statically, but two restrictions are enforced:
	   1) The pty open routine is changed to handle the O_EXCL flag
	      on the open properly if it doesn't already.  That is, if the 
	      reference count is not zero, the open fails (ie: only one 
	      open at a time when this is on!)
	   2) The system code affected is changed to always use O_EXCL 
	      on open for the slave side of the pty when doing the 
	      allocation.  Thus, if someone has the slave open, the pty in
	      question will be skipped.  This leaves a denial of service
	      attack possibility (tie up all the slaves) but does not allow
	      someone to "sit" on a pty until someone comes along.
	   3) All pty slave ends are opened by the system as mode 700, or
	      chmod'd 700 before being opened.

Does this not solve the problem?  It appears that this is what MIPS has
done, and it appears to be effective.  What I was able to do on other
machines here didn't work on our M3260 RiscOS machine running RiscOS 4.52.
The RS/6000 doesn't have visible slave pty ends in the /dev directory at
all.

>As for explaining this to your boss: I'm sorry I can't be any help here.
>I note that it is a lot more cost effective for FooBar Computer Co. to
>make fixes once and distribute them to 1000 admins than to have 1000
>admins each make fixes for themselves.

IF "FooBar" Computer Company (I could name a few of these "Foobar"s)
bothers to do anything at all.  There is no guarantee they will.

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning at nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.