Xref: utzoo comp.unix.wizards:25259 alt.security:2366 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!pcserver2!kdenning From: kdenning@pcserver2.naitc.com (Karl Denninger) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 4: What You Can Look Forward To Summary: Ok, how about this for an answer then? Message-ID: <1991Apr30.164646.11693@pcserver2.naitc.com> Date: 30 Apr 91 16:46:46 GMT References: <13218@goofy.Apple.COM> <1991Apr29.222139.21284@pcserver2.naitc.com> <14683@ulysses.att.com> Organization: AC Nielsen, Bannockburn IL USA Lines: 93 In article <14683@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >In article <1991Apr29.222139.21284@pcserver2.naitc.com>, kdenning@pcserver2.naitc.com (Karl Denninger) writes: > >[mostly deleted] > >Dan is caught between a rock and a hard place here. He knows of >certain security problems in many existing systems. What should he do >with the information? > >One answer is to post and be damned. Lots of people advocate that. I >sometimes do, myself -- as noted, the crackers often know the problems, >too. In this case, the bug is very widespread. > >Another answer is to tell vendors and CERT. This is a favorite of >folks who don't like the first answer. He's tried that; according to >his earlier postings, some vendors, at least, aren't interested. Neither was Interactive with their u_area bug (it was world-writable!) until someone posted code which exploited the bug. CERT wasn't even interested (I guess they consider ISC's offering not to be of any importance). I am on the CERT list -- there was no notice of that problem at all. It got fixed in about two weeks once the code to exploit it was posted. ISC put their head in the sand until outrageous users started flooding their phone lines. Nothing like hitting someone over the head with a baseball bat to get their attention with these kinds of things. >Face it, there's no satisfying everyone. What Dan has done -- offered >details to anyone who can prove his or her legitimacy -- is certainly >defensible as an answer. Your and I may not (or may) agree with it, >but it's as reasonable a choice as either of the first two. Well, I've sent him mail, and he sent back some "hints". That is not details. And I'm as real, and as legitimate, as anyone on the net. I'm responsible for the wide-area network security here at this facility. Now I'm stuck with trying to justify hacking at a problem on the strength of someone's word from the net. This doesn't work in industry where you have real work to get done! Unfortunately, the powers that be here (and I suspect at lots of other companies) disagree strongly with people spending their time hacking while looking for bugs in the pty drivers (or elsewhere). I can EASILY make a business case for fixing the stuff -- IF I can show where the problem is, and show a hard example. So far my probing has been futile on terminals with "mesg n" set. >> From the manual pages [on TIOCSTI], I believe it shouldn't work. > >I believe you're barking up the wrong termite-infested tree. Although >I haven't seen a detailed report on the problem, there were sufficient >clues in the first three parts that I'm fairly certain I know what rock >these bugs are hiding under. To be sure, I'm already predisposed to >think in those terms -- Dan did cite my paper as relevant. (For those >who are interested, the citation is ``The "Session Tty" Manager'' >Bellovin, S.M., Proceedings of USENIX Conference, San Francisco, CA, >Jun 30, 1988, P339-354.) I've got a few ideas too, but most of them rely on the pty being world-writable. I normally run with "mesg n"; if these bugs get through >that< then I really do want to hear about it, and exactly what he's talking about. Now if the manual pages are wrong (ie: they're lying) with regards to the restrictions on some of those ioctl calls...... >Incidentally, offering (threatening?) to post programs that exploit >the bugs is in itself a pretty good warrantee. Dan wouldn't risk his >reputation if he didn't have those programs written already, I suspect. > > --Steve Bellovin This is true. So assume that the crackers already know about this. Where does this leave you? 1) The bad guys already know what is broken, and how to exploit it. They WILL exploit it given the chance. They have as good an information distribution system than we do, and aren't afraid to use it -- unlike some of us. 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. -- 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.