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

[Karl Denninger]

In article <14683 at ulysses.att.com> smb at ulysses.att.com (Steven Bellovin) writes:
>In article <1991Apr29.222139.21284 at pcserver2.naitc.com>, kdenning at 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 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.