Xref: utzoo comp.unix.wizards:25306 alt.security:2389 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!pcserver2!genesis!kdenning From: kdenning@genesis.Naitc.Com (Karl Denninger) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 4: What You Can Look Forward To Summary: More on the pty problems Message-ID: <1991May1.201408.16204@pcserver2.naitc.com> Date: 1 May 91 20:14:08 GMT References: <14683@ulysses.att.com> <1991Apr30.164646.11693@pcserver2.naitc.com> <26844:May100:59:2591@kramden.acf.nyu.edu> Sender: usenet@pcserver2.naitc.com (News Poster for NNTP) Organization: AC Nielsen Co., Bannockburn IL Lines: 78 Nntp-Posting-Host: genesis.naitc.com In article <26844:May100:59:2591@kramden.acf.nyu.edu> brnstnd@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@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.