Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

24 views
Skip to first unread message

Dan Bernstein

unread,
Apr 26, 1991, 10:04:43 AM4/26/91
to
To close this series of postings, I'd like to briefly survey the state
of tty security. I'm sorry I haven't been able to respond personally or
quickly to everyone's mail on this issue.

Just a few years ago I was exploring the depths of an old Ultrix system.
It didn't take a genius to notice the occasional background jobs gone
astray---obviously any user could affect any other user's tty, despite
vhangup(). Soon I had ``blip'', a reasonably powerful tty mode mangler
that could act both as a concise stty and as a tty security breaker.
With it I could write arbitrary text to anyone's tty, TIOCSTI terminal
input, change tty mode settings, send tty signals, and so on.

So I sent copies of the code and documentation to the sysadmin at that
site, and posted a 300-line analysis to comp.unix.wizards. As I recall,
there were three responses. One asked what I was talking about. One was
from the admin describing what I now know to be only a partial fix. One
was from Steve Bellovin referring me to his then-new Session Tty paper
for descriptions of a few of the bugs as well as a complete (but
complex) fix for System V which, to my knowledge, has never been
implemented.

blip still works on every BSD UNIX machine I can find. It is trivial to
adapt to POSIX. And it has, unfortunately, been spreading slowly around
the net under the name of ``factor.''

That's right. Every available BSD UNIX machine allows any user to write
or type arbitrary characters on the tty of another user. With good
timing the attacker can even make his attack invisible---the moment a
sysadmin types a root command, someone could be piggybacking a command
like cp /bin/sh /tmp/sh; chmod 4755 /tmp/sh. And it gets worse.

How many people know how to exploit these bugs? Far too many, I'm sure,
but not enough to shock other admins into seeing the magnitude of this
problem. And this pales beside the examples set by vendors. I tell Sun
how insecure ttys are, and offer a bandaid: Sun tells me that POSIX
fixes everything, and refuses to admit that a bandaid is necessary.
Convex is finally waking up, but is still under the delusion that one
kernel kludge after another (from vhangup() to POSIX sessions and
beyond) will solve the fundamental problems of statically allocated,
world-usable ttys.

Berkeley is finally showing some interest in fixing the bugs, but it
will be years before vendors have picked up the changes, and several
years before the average machine on the net is safe. Sorry, but I'm not
going to wait that long. I am sick of constantly wondering whether my
users know enough to break security. I am sick of hearing that POSIX
fixes the problems. I am sick of seeing vendors blind themselves to such
a fundamental set of holes. You should be sick of it too.

So here's what I'm doing about it.

1. In part 3 of this series I outlined a reasonably simple set of fixes.
If you have a BSD-derived system where something in the plan doesn't
work, please post your comments here and we'll see what has to be done.
If you don't have source, and you want to be notified as soon as binary
patches are available, tell CERT your hardware type and OS version at
ce...@cert.sei.cmu.edu.

2. I will dedicate some of my free time to working with vendors and
established authorities like CERT interested in tightening up tty
security.

3. So that programmers are insulated from these changes in the pty
subsystem, I commit myself to porting my pty manager to any platform I
have access to.

4. I will attempt to outline a minimal set of (optional) changes to the
POSIX standard to keep the standard from interfering with tty security.
I would be interested in hearing from POSIX committee members interested
in helping with this.

5. On or around October 29, 1992, I will publish a set of tiger programs
that test for and exploit the failures in BSD tty security that I have
described.

6. I will give further details on the security holes to anyone who
convinces me that he has a legitimate interest. That means I want a
verifiable chain of people and phone numbers from the contact for a
major network down to whoever wants the information, plus a better
excuse than ``I haven't read Bellovin's paper or your paper yet.''
If you simply want someone other than me to tell you that the holes
exist, ask bos...@okeeffe.berkeley.edu. (That's Keith Bostic, the guy in
charge of BSD; don't be surprised if he doesn't get to your message
immediately.) Please don't believe vendor assurances that the holes have
been fixed---they haven't.

I hope I've yelled enough about these bugs now. I hope that soon there
won't be anything to yell about.

---Dan

Kartik Subbarao

unread,
Apr 27, 1991, 1:04:44 PM4/27/91
to
In article <3600:Apr2614:04:43...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
>To close this series of postings, I'd like to briefly survey the state
>of tty security. I'm sorry I haven't been able to respond personally or
>quickly to everyone's mail on this issue.
>
>Just a few years ago I was exploring the depths of an old Ultrix system.

``An old Ultrix system'', he says.

>So I sent copies of the code and documentation to the sysadmin at that
>site,

``Site.'' Another nice word.

Gee, Dan likes to forget history quickly ;-).

-Kartik


--
internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'`

subb...@phoenix.Princeton.EDU -| Internet
kar...@silvertone.Princeton.EDU (NeXT mail)
SUBB...@PUCC.BITNET - Bitnet

Steven Bellovin

unread,
Apr 29, 1991, 10:32:44 PM4/29/91
to
In article <1991Apr29.2...@pcserver2.naitc.com>, kden...@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.

Robert Morris had his answer to the problem of how you get vendors to
fix security problems, but it bought him a felony conviction. Most
people consider that too high a price to pay.

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.

> 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.)

> If this is not true, I would like details. Not just "fixes", or
> pontificating, but details. I can patch around lots of things, and
> replace system code if necessary. Without some DETAILS it's
> difficult at best.

To annouce the details now would be to opt for choice 1. Dan has
already rejected that approach. For those who don't believe the bugs
exist, he has offered Keith Bostic as a reference. You can't do better
than Keith, but if the network wants, I'll offer myself as another
reference -- Dan and I have corresponded enough that I'm sure he'll
trust me with the info... Not that I really need to see it -- as I
said, I think I know where the bodies are buried. (Gee -- that's my
third metaphor for the same problem, and all in one posting...)

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

Dan Bernstein

unread,
Apr 29, 1991, 7:33:43 PM4/29/91
to
In article <13...@goofy.Apple.COM> e...@Apple.COM (Ed Carp) writes:
> In article <3600:Apr2614:04:43...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >6. I will give further details on the security holes to anyone who
> >convinces me that he has a legitimate interest.
> Um, what IS this bullshit?

I'm sorry if you find this too restrictive. I also advise you to read
the articles that you claim to be responding to: in item 5 I set a date
upon which I will disclose full details of the security holes. While I
understand that people without a legitimate interest in the security
holes (you, for instance?) don't want to wait that long, I'd feel guilty
if I didn't give vendors a grace period to clean up their act.

> Your pathetic excuses
> about protecting the information from "black hats" is unmitigated bullshit.

I have never made any such excuses. I must add, sir, that the accuracy,
originality, and sophistication of your rhetoric are matched only by its
grammatical brilliance.

> The only thing you are doing is concealing any valuable information that you
> may have from the people who have a genuine need for your information.

If you had a genuine need for the information, then you'd be explaining
that need to me rather than blathering all over netnews.

> The
> folks who already care about cracking into systems already know about this
> stuff anyway.

An NCSC trusted systems reviewer, among others, has told me that he is
unfamiliar with the holes in question. Have you heard of the NCSC?

You remind me of the people who say (without knowing, of course) that
sendmail's debug hole was widely known before RTM made a fool of
himself. Does it make you feel wizardly to pretend that you know what
you're talking about?

---Dan

Karl Denninger

unread,
Apr 30, 1991, 12:46:46 PM4/30/91
to
In article <14...@ulysses.att.com> s...@ulysses.att.com (Steven Bellovin) writes:
>In article <1991Apr29.2...@pcserver2.naitc.com>, kden...@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
kden...@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.

Karl Denninger

unread,
Apr 30, 1991, 6:47:40 PM4/30/91
to
>To close this series of postings, I'd like to briefly survey the state
>of tty security. I'm sorry I haven't been able to respond personally or
>quickly to everyone's mail on this issue.
>
>Just a few years ago I was exploring the depths of an old Ultrix system.
>It didn't take a genius to notice the occasional background jobs gone
>astray---obviously any user could affect any other user's tty, despite
>vhangup(). Soon I had ``blip'', a reasonably powerful tty mode mangler
>that could act both as a concise stty and as a tty security breaker.
>With it I could write arbitrary text to anyone's tty, TIOCSTI terminal
>input, change tty mode settings, send tty signals, and so on.

MIPS has apparently fixed most of the ways this can be exploited.

The most obvious attempts, taking over "unused" ptys slave ends, result in
the system skipping them when assignment time comes around. This prevents
the most obvious ways to exploit this hole. I believe MIPS may be using
some form of "O_EXCL" to prevent multiple access....

The RS/6000 dynamically creates ptys, and thus doesn't suffer from the
problem at all.

ISC, Apple (A/UX), and Sun, DO have the problem.

KUDOS TO MIPS ON THIS ONE. They got it right.

Perry E. Metzger

unread,
Apr 30, 1991, 3:21:32 PM4/30/91
to
In article <13...@goofy.Apple.COM> e...@Apple.COM (Ed Carp) writes:
>>6. I will give further details on the security holes to anyone who
>>convinces me that he has a legitimate interest. That means I want a
>>verifiable chain of people and phone numbers from the contact for a
>>major network down to whoever wants the information, plus a better

>Um, what IS this bullshit? Who the hell are you to set yourself up
>as some sort of net.god and tell us that you will "bless" us with all
>your neat little hacks and info only if we satisfy your little set of
>rules? Your pathetic excuses about protecting the information from


>"black hats" is unmitigated bullshit.

I see you work for U.S. West Consulting, Mr. Carp. I hope you are a
bit more polite and rational with your customers and employers; the
consulting buisness is based largely on customer relations.

As for your contention that Mr. Bernstein is wrong for not posting the
details of the security holes he has uncovered, you may or may not be
right, but one certainly can't tell through the layers of foul
language you have coated your message wtih. Mr. Bernstein certainly
has the right to do what he likes, and its certainly antisocial, not
to mention destructive to your image with your peers, when you flame
at him in that manner. It is also quite unlikely that insults and
villification will get him to change his mind about publically
releasing his information.

Perry Metzger

Matthew T. Russotto

unread,
Apr 30, 1991, 6:02:59 PM4/30/91
to
In article <1991Apr29.2...@pcserver2.naitc.com> kden...@pcserver2.naitc.com (Karl Denninger) writes:
>
>I have to agree.
>
>I am in charge of Internet and external security here. There is another
>group which is in charge of internal security.
>
>Both of us, I'm sure, would like to have some FACTS on this stuff. TIOCSTI
>is well known as a problem, but I thought that was supposed to be restricted
>to use by root (unless it's your control terminal....).

The trick is to grab control of the next unused terminal. Then, the next
sucker to log in is vulnerable. It works.

>I think I just heard you say that was all malarkey, that anyone could
>TIOCSTI my root session while logged in over a pty, and that you could
>exploit those items to gain control of my session.
>
>From the manual pages, I believe it shouldn't work.

It worked on certain Ultrix revisions-- can't say anything about any other
systems.
--
Matthew T. Russotto russ...@eng.umd.edu russ...@wam.umd.edu
.sig under construction, like the rest of this campus.

Sean Eric Fagan

unread,
Apr 30, 1991, 8:21:14 PM4/30/91
to
In article <1991Apr30....@mp.cs.niu.edu> ric...@mp.cs.niu.edu (Neil Rickert) writes:
> And what exactly is there to stop somebody running a daemon which grabs
>access to a pty immediately after it has been assigned, or immediately
>after it has been dynamically created, but before public write access has
>been turned off.

Who says they get created with public access turned *on*?

--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
s...@kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Dave Hayes

unread,
Apr 30, 1991, 6:31:29 PM4/30/91
to
e...@Apple.COM (Ed Carp) writes:

>>6. I will give further details on the security holes to anyone who
>>convinces me that he has a legitimate interest. That means I want a
>>verifiable chain of people and phone numbers from the contact for a
>>major network down to whoever wants the information, plus a better

>Um, what IS this bullshit?

What indeed? Methinks it IS just that.

> Who the hell are you to set yourself up as some sort
>of net.god and tell us that you will "bless" us with all your neat little hacks
>and info only if we satisfy your little set of rules? Your pathetic excuses
>about protecting the information from "black hats" is unmitigated bullshit.

THANK YOU for saying this! I'm glad someone out there has sense.

>The only thing you are doing is concealing any valuable information that you

>may have from the people who have a genuine need for your information. The


>folks who already care about cracking into systems already know about this

>stuff anyway. Get real.

Hear, hear!

--
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ames!elroy!dxh

There is a saying: "I believe it because it is impossible"
If you make any study of people in a state of what they are pleased to call
belief, you will find that you can usually best describe them by the saying:
"My belief has made me impossible."

Dave Hayes

unread,
Apr 30, 1991, 6:42:35 PM4/30/91
to
s...@ulysses.att.com (Steven Bellovin) writes:

>In article <1991Apr29.2...@pcserver2.naitc.com>, kden...@pcserver2.naitc.com (Karl Denninger) writes:

>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?

In my opinon (for whatever that's worth) he should publish it widely and
loudly. (here I go again being flame bait...)

>Face it, there's no satisfying everyone.

This is all TOO true. *sigh*

>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.

I see what you are saying, but I have to disagree. Why has Dan even POSTED
that such holes exist, if he is not willing to disclose the details to
us system admins that are going to be of necessity interested in the problem?

WOuldn't it have been better to just report this to CERT and vendors and
leave it go at that? That way, those of us who he claims have no justification
for the details wouldn't even know to ask him, right?

Personally, I would like to know exactly what his criterion is. I believe I
have extremely valid reasons for knowing these details...my paycheck happens
to refelct these reasons. Naturally I responded to his #6 item...believing
full well that he could validate my legitimacy.

He hasn't even tried. It would appear, (if I may evaluate for him) that his
whole purpose stems from some need to have a secret that you don't. Nyahhh.
8)

I think he shouldn't have said a damn thing.

Neil Rickert

unread,
Apr 30, 1991, 7:12:35 PM4/30/91
to
In article <1991Apr30.2...@pcserver2.naitc.com> kden...@pcserver2.naitc.com (Karl Denninger) writes:
>
>The most obvious attempts, taking over "unused" ptys slave ends, result in
>the system skipping them when assignment time comes around. This prevents
>
>The RS/6000 dynamically creates ptys, and thus doesn't suffer from the
>problem at all.

And what exactly is there to stop somebody running a daemon which grabs


access to a pty immediately after it has been assigned, or immediately
after it has been dynamically created, but before public write access has
been turned off.


--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neil W. Rickert, Computer Science <ric...@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940

Dan Bernstein

unread,
Apr 30, 1991, 8:59:25 PM4/30/91
to
In article <1991Apr30.1...@pcserver2.naitc.com> kden...@pcserver2.naitc.com (Karl Denninger) writes:
> In article <14...@ulysses.att.com> s...@ulysses.att.com (Steven Bellovin) writes:
> >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.

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.

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.

> 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.

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.

---Dan

Steve Simmons

unread,
Apr 30, 1991, 9:06:57 PM4/30/91
to
s...@ulysses.att.com (Steven Bellovin) writes:
>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.

kden...@pcserver2.naitc.com (Karl Denninger) writes:

>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.

Some CERT person may correct me, but I believe that CERT only
makes public announcements when a fix or workaround is already
available.
--
"FACT: less than 10% of the psychiatrists in the US are actually
practicing cannibals." Rod Johnson

Karl Denninger

unread,
May 1, 1991, 12:51:40 AM5/1/91
to
In article <1991Apr30....@mp.cs.niu.edu> ric...@mp.cs.niu.edu (Neil Rickert) writes:
>In article <1991Apr30.2...@pcserver2.naitc.com> kden...@pcserver2.naitc.com (Karl Denninger) writes:
>>
>>The most obvious attempts, taking over "unused" ptys slave ends, result in
>>the system skipping them when assignment time comes around. This prevents
>>
>>The RS/6000 dynamically creates ptys, and thus doesn't suffer from the
>>problem at all.
>
> And what exactly is there to stop somebody running a daemon which grabs
>access to a pty immediately after it has been assigned, or immediately
>after it has been dynamically created, but before public write access has
>been turned off.

Well, one could open it with O_EXCL turned on. One and only ONE process can
get to that pty until it releases the exclusive flag. The process can do
that well after it's turned off public write access.

Heck, leave it set exclusive. Most things that have to open a terminal
again would use /dev/tty, which shouldn't get in trouble with this scheme.

If that is implemented for ptys, that should fit the requirement nicely.

Ed Carp

unread,
Apr 29, 1991, 12:37:24 PM4/29/91
to

>6. I will give further details on the security holes to anyone who
>convinces me that he has a legitimate interest. That means I want a
>verifiable chain of people and phone numbers from the contact for a
>major network down to whoever wants the information, plus a better

Um, what IS this bullshit? Who the hell are you to set yourself up as some sort


of net.god and tell us that you will "bless" us with all your neat little hacks
and info only if we satisfy your little set of rules? Your pathetic excuses
about protecting the information from "black hats" is unmitigated bullshit.

The only thing you are doing is concealing any valuable information that you
may have from the people who have a genuine need for your information. The
folks who already care about cracking into systems already know about this

stuff anyway. Get real. You sound like Gene Spafford when the baloon went
up on the Internet virus/Morris stuff. He, too, wanted to "protect" the
unwashed from knowing what was going on. I'm glad to see that he has a more
enlightened point of view.
--
Ed Carp N7EKG/6 e...@khijol.UUCP ...uunet!khijol!erc
UUWEST Consulting Alameda, CA 415/814-0550

Computers HAVE caused a revolution in how much information we
can safely ignore! --ro...@ux1.cso.uiuc.edu (Rob Schaeffer)

-- Absolutely unabashed Gates McFadden groupie! --

Steve Blair

unread,
May 1, 1991, 5:09:44 PM5/1/91
to
Ed Carp sez:

|> Being a
|> system administrator of a hundred systems doesn't prove you're a good guy,

I can agree in at least one case, that someone who apparently seemed
on paper a good sysadmin, was using sites' to break into other sites.

This person had a choice at the unnamed employer - leave or
be terminated. That doesn't imply prosecution/lack therof.

|> Yes, but FooBar Co. (as you yourself have stated) just doesn't have any interest There's NO WAY that you're going to
|> get all vendors to distribute fixes, let alone distribute them FOR FREE.


|> --
|> Ed Carp N7EKG/6 e...@khijol.UUCP ...uunet!khijol!erc
|> UUWEST Consulting Alameda, CA 415/814-0550

While I agree with several posters, SOME companies DO CARE, and
do insure that fixes get distributed. Size of the company,
&/or any arguments about the customer bas is ILLOGICAL. If the
>customer< chooses not to RTFM(bug list), or call about something
then that's his choice. But the vendors who DO DISTRIBUTE SECURITY
fixes will be remembered, in things such as customer loyalty!!

The small 1 or even 2 time cost of the fix, regardless of media
to achieve *satisfaction* of being "supported right" will always
far outweigh the minor cost associated with distribution. The
possibilities of legal action in lawyer costs substantiate this!!

That will be a decisive factor, as wel become more and more 'lectronic !!!!!

--
Steve Blair DELL UNIX DIVISION sbl...@upurbmw.dell.com
================================================================

Matthew T. Russotto

unread,
May 1, 1991, 1:06:41 PM5/1/91
to
>The most obvious attempts, taking over "unused" ptys slave ends, result in
>the system skipping them when assignment time comes around. This prevents
>the most obvious ways to exploit this hole. I believe MIPS may be using
>some form of "O_EXCL" to prevent multiple access....
>
>The RS/6000 dynamically creates ptys, and thus doesn't suffer from the
>problem at all.
>
>ISC, Apple (A/UX), and Sun, DO have the problem.
>
>KUDOS TO MIPS ON THIS ONE. They got it right.

With Sun and Ultrix, you seem to be able to affect telnets while the 'login'
and 'passwd:' prompts are up-- once the session starts, Ultrix stops the
TIOCSTI process, and Sun hangs up both the incoming telnet and the TIOCSTI
process. A/UX doesn't even have TIOCSTI-- am I missing something?

Ed Carp

unread,
May 1, 1991, 1:57:24 PM5/1/91
to

>Let me be more explicit. I consider vendors to have a legitimate

Oh? I do consulting for a vendor, notably Apple. I also do consulting
for a number of very large companies in the bay area, notably a very large
public utility. They also have a vested interest in anything that would
enhance their security.

>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.

Well, then ... post it in alt.sources or alt.security.sources. Calls for
votes, anyone?

IMHO, your attitude is irrational. How many sites do I have to administer
to qualify? One? Five? A hundred?

You haven't addressed the issue of whether I'm a cracker or not. Being a


system administrator of a hundred systems doesn't prove you're a good guy,

any more than being the administrator of one makes you a bad guy. System
administrators of a few sites face many (not ALL) of the same headaches of
a large site. Backups, security, user management and disk management, just
to name a few.

>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.

Yes, but FooBar Co. (as you yourself have stated) just doesn't have any interest
in fixing the bugs! Besides, do you have any idea how many different computer
systems you're talking about impacting? There's NO WAY that you're going to


get all vendors to distribute fixes, let alone distribute them FOR FREE.
--
Ed Carp N7EKG/6 e...@khijol.UUCP ...uunet!khijol!erc
UUWEST Consulting Alameda, CA 415/814-0550

Computers HAVE caused a revolution in how much information we

Dan Bernstein

unread,
May 1, 1991, 1:10:56 PM5/1/91
to
In article <1991May1....@lokkur.dexter.mi.us> s...@lokkur.dexter.mi.us (Steve Simmons) writes:
> Some CERT person may correct me, but I believe that CERT only
> makes public announcements when a fix or workaround is already
> available.

May I remind you that a fix *is* available? It's not a plug 'n' play
patch, but it does the job, and I'm perfectly willing to help people
implement it if something isn't clear in the original description. I
went to quite a bit of effort to put part 3 together, so it's rather
depressing to see someone say that the fixes don't exist.

I expect that CERT will announce when binary patches are available to
fix these holes on some machine. Sites that want to speed this process
should complain to their vendors. Sites that have modified their systems
can still apply the fixes I've explained.

---Dan

Jyrki Kuoppala

unread,
May 1, 1991, 10:08:15 AM5/1/91
to
>You remind me of the people who say (without knowing, of course) that
>sendmail's debug hole was widely known before RTM made a fool of
>himself. Does it make you feel wizardly to pretend that you know what
>you're talking about?

For the record, I also don't believe that the sendmail debug feature
was 'widely known', whatever that means. But I personally ran into it
independently, examining the SMTP protocol, and then noticed that
strange things begin to happen after the (undocumented, I think, at
least I found it by chance) debug command was given. This was some
time before the Internet worm episode. And no, I didn't publicize it
widely, just discussed it with a few friends of mine and the local
administrators.

Back then, I didn't know of a good way to communicate such holes and
probably didn't even think anyone would be that interested in it.
Don't know, perhaps if I had posted it to a newsgroup back then the
worm episode wouldn't have happened. Not that I say it would have
been good or bad.

//Jyrki

Karl Denninger

unread,
May 1, 1991, 4:55:07 PM5/1/91
to
In article <1991May1.1...@eng.umd.edu> russ...@eng.umd.edu (Matthew T. Russotto) writes:
>In article <1991Apr30.2...@pcserver2.naitc.com> kden...@pcserver2.naitc.com (Karl Denninger) writes:
>>
>>The most obvious attempts, taking over "unused" ptys slave ends, result in
>>the system skipping them when assignment time comes around. This prevents
>>the most obvious ways to exploit this hole. I believe MIPS may be using
>>some form of "O_EXCL" to prevent multiple access....
>>
>>The RS/6000 dynamically creates ptys, and thus doesn't suffer from the
>>problem at all.
>>
>>ISC, Apple (A/UX), and Sun, DO have the problem.
>>
>>KUDOS TO MIPS ON THIS ONE. They got it right.
>
>With Sun and Ultrix, you seem to be able to affect telnets while the 'login'
>and 'passwd:' prompts are up-- once the session starts, Ultrix stops the
>TIOCSTI process, and Sun hangs up both the incoming telnet and the TIOCSTI
>process. A/UX doesn't even have TIOCSTI-- am I missing something?

Ultrix and MIPS are only related in that MIPS supplies DEC with the chips.

We have a MIPS RISCserver here, model 3260. Runs Risc/OS 4.52. Darn nice
implementation. I keep finding more and more things to like about it, and
only a few I don't like.

DEC's porting base for Ultrix is not related to RiscOS as far as I know.

Karl Denninger

unread,
May 1, 1991, 4:14:08 PM5/1/91
to
>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.

Paul Pomes - UofIllinois CSO

unread,
Apr 29, 1991, 5:06:03 PM4/29/91
to
e...@Apple.COM (Ed Carp) writes:

>Um, what IS this bullshit? Who the hell are you to set yourself up as some sort
>of net.god and tell us that you will "bless" us with all your neat little hacks
>and info only if we satisfy your little set of rules? Your pathetic excuses
>about protecting the information from "black hats" is unmitigated bullshit.

Did you wake up on the wrong side of the bed this morning? Dan is free to
send information to whoever he chooses on whatever basis he chooses. If you
don't like, don't play. Better yet, show off YOUR knowledge and post the
information yourself.

So flame away and enlarge kill files everywhere with your name. The audience
will be that much smaller the next time you need help.

/pbp
--
Paul Pomes

UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: pa...@uxc.cso.uiuc.edu
US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910

William Walker

unread,
May 1, 1991, 1:46:30 PM5/1/91
to
In article <1991Apr30....@jato.jpl.nasa.gov>, da...@jato.jpl.nasa.gov (Dave Hayes) writes:

> s...@ulysses.att.com (Steven Bellovin) writes:
>
> >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.
>
> I see what you are saying, but I have to disagree. Why has Dan even POSTED
> that such holes exist, if he is not willing to disclose the details to
> us system admins that are going to be of necessity interested in the problem?
^^^^^^^^^^^^^

ok, so you *are* a system admin with a legit need to know. so what's the big
deal with sending him a set of references??


do you want every bored CS major between here and australia finding out
about those holes a week or so before you get your patch tapes from the
vendor?

>
> Personally, I would like to know exactly what his criterion is. I believe I
> have extremely valid reasons for knowing these details...my paycheck happens
> to refelct these reasons. Naturally I responded to his #6 item...believing
> full well that he could validate my legitimacy.
>

so what do you do if you find a nifty little bug?? you tell the vendor
and CERT, CERT makes it known to it's brain/talent trust, contacts the
vendor who says "BFD". what about the guy *without* source?? how is
he ever going to get the hole patched? unless the customers pressure
the vendor, NO changes will ever be made unless it is the old "fixed
in the next release" line, send us a check.... this "approval" arrangement
also sounds kinda hokey to me, but i can't think of a better medium
between leaving gaping holes under the carpet and posting potentially
dangerous code on a public forum accessible to thousands of bored hacker
wannabe's.

just another $.02
bill.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bill Walker - Overlord of Gateway Traffic, Keeper of all that is PD,
Maintainer of the Almighty Source Tree, Worshipper of K+R,
Altar-boy at the Temple of "Bob", Resource in Residence,
Patcher of Perl, Configurer of the Holy Sendmail...
wrw...@rsi.prc.com -- PRC, a wholly owned subsidiary of Black+Decker Inc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Jyrki Kuoppala

unread,
May 1, 1991, 10:21:59 AM5/1/91
to
In article <1991Apr30.1...@pcserver2.naitc.com>, kdenning@pcserver2 (Karl Denninger) writes:
>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.

The program doing the stuffing can just open the pty before you say
'mesg n' on it. Looking at what Dan has posted, I wouldn't be
surprised if there were other ways also, but I don't have more
information on that

>Now if the manual pages are wrong (ie: they're lying) with regards to the
>restrictions on some of those ioctl calls......

I don't think they are lying, just that at least some of the
restrictions can be gotten around.

//Jyrki

Jyrki Kuoppala

unread,
May 1, 1991, 9:52:12 AM5/1/91
to
In article <1991Apr29.2...@pcserver2.naitc.com>, kdenning@pcserver2 (Karl Denninger) writes:
>Both of us, I'm sure, would like to have some FACTS on this stuff. TIOCSTI
>is well known as a problem, but I thought that was supposed to be restricted
>to use by root (unless it's your control terminal....).
>
>I think I just heard you say that was all malarkey, that anyone could
>TIOCSTI my root session while logged in over a pty, and that you could
>exploit those items to gain control of my session.
>
>From the manual pages, I believe it shouldn't work.
>
>If this is not true, I would like details. Not just "fixes", or
>pontificating, but details. I can patch around lots of things, and replace
>system code if necessary. Without some DETAILS it's difficult at best.

Last I checked, TIOCSTI can be used on typical BSD systems whenever
you can open the tty for writing - which on most systems means always,
since when no one is logged on on the tty, the tty is writable to all.
On newer systems the owner and modes are changed when a user logs in
so that the tty is writable only by group tty, but this does not
really help since the program which wants to do TIOCSTI can open the
tty in advance.

It's been a while - couple of years or so - when I studied it, so I
don't remember all the details, but essentially the idea is that on
typical 4.3 bsd-derived systems any process can do TIOCNOTTY (notty,
notty ;-) and after that the first tty it opens becomes the control
terminal, after which you can open /dev/tty and do TIOCSTI on it.

The POSIX session stuff might have changed this on some newer
releases, I haven't checked.

Then there's also other tty stuff, like being able to do 'stty 0' on
another user's line on USG-style systems to log them off or change
their stty parametres in general. I'm not sure if this works on BSD
systems.

Also, reading another terminal's input from the tty queues works
pretty nicely at least when that another terminal is on a 1200 bps
modem line. There was a program posted to the net to do this a while
ago, the program needed some modifications but I got it working on 4.3
bsd ttys and SVR2 ttys (requires read access to kmem on both).

If anyone needs more info, I think I could with some effort find the
program to do the TIOC{NOTTY,STI} stuff, but it's really not that hard
to write.

Then of course there are these wonderful Quality Assured, Value Added
bsd-derived systems nowadays - on this machine I have found myself
several times on someone other's screen session, when for example
using ange-ftp from emacs.

//Jyrki

Jeff d'Arcy

unread,
May 1, 1991, 1:24:27 PM5/1/91
to
kden...@pcserver2.naitc.com (Karl Denninger) writes:
>ISC put their head in the sand until outrageous users started flooding
^^^^^^^^^^^^^^^^
I've met a few of these. 8]

>>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?

Risk his what? Sorry, couldn't resist. As much as I enjoy Bernstein-bashing,
that's not my purpose here. The fact is that Dan would hardly be the first
person to make such an offer without having the goods to back it up. Maybe he
will have them when the time comes; maybe he won't.

In any case, I think *posting* them would be irresponsible since, as Dan points
out himself, it will be *years* before the number of vulnerable vendors becomes
small enough to be discounted. I think sending the programs to "responsible
individuals" (whoever they are) would be much better.

Dave Hayes

unread,
May 2, 1991, 4:41:32 PM5/2/91
to
brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:

>Somehow certain people have formed the mistaken impression that I have
>been treating large sites differently from small sites. As I have tried
>to explain, I do *not* see a fine line between the administrator of one
>machine and the manager of a network of ten thousand machines. I have
>not made and will not make a policy of sending break code to anyone who
>asks---exactly *because* wide distribution of the code will eventually
>reach the ``bad guys'', will affect practically every UNIX machine on
>the Internet, and won't be traceable. So (as Dave Hayes can assure you)
>I haven't been sending code to people merely because they manage a
>``large enough'' network.

Yes, I can vouch for that. Dan has persisted in an arrogant and counter-survival
attitude which affects the lives of nearly every damn sys admin responsible
for computer security.

Consider...good computer crackers can find out exactly how to exploit
these holes from the information Dan has "graciously" (read 'teasingly')
given us all. Why NOT distribute the code involved? The damage is already
done.

In fact, Dan has made a whole LOT of people 'wrong' in a sense of
giving out a potential hole, and then proposing some long and tired
hack to a system to patch it. Does this work? Has anyone tried it?
Is it comphrehensive?

Personally, I don't trust anyone that doesn't trust me. (COmmon sense)
There's no way I would trust the integrity and completeness of Dan's
patch...even though he may be competant enough to have provided the
correct information. So that 'patch' he posted is basically worthless
to me. (Yes, I could waste a good week figuring these things out for
myself...this is neither desireable or the real point.)

How many other sys admins out there feel like I do? I'd really like
to know.

>This may not be the optimal policy for handling a security hole, but
>it's the best policy I've come up with, and I'm not going to listen to
>complaints from people who can neither formulate a consistent
>alternative policy nor think through its effects. The intelligent man
>does not criticize what he cannot improve.

Well, to "improve" something has different meaning to different people.
I can not only criticize, I can supply you with an alternative. Provide
enough details to enable someone to write a comprehensive program that
can check for the existence of the holes that you specify on any system...
then publish it. It's that simple.

>---Dan

--
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ames!elroy!dxh

There is no greater calamity for a nation or individual
than not finding contentment in one's sufficiency.

Karl Denninger

unread,
Apr 29, 1991, 6:21:39 PM4/29/91
to
In article <13...@goofy.Apple.COM> e...@Apple.COM (Ed Carp) writes:
>In article <3600:Apr2614:04:43...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>>6. I will give further details on the security holes to anyone who
>>convinces me that he has a legitimate interest. That means I want a
>>verifiable chain of people and phone numbers from the contact for a
>>major network down to whoever wants the information, plus a better
>
>Um, what IS this bullshit? Who the hell are you to set yourself up as some sort
>of net.god and tell us that you will "bless" us with all your neat little hacks
>and info only if we satisfy your little set of rules?

(lots more flamage deleted)

I have to agree.

I am in charge of Internet and external security here. There is another
group which is in charge of internal security.

Both of us, I'm sure, would like to have some FACTS on this stuff. TIOCSTI


is well known as a problem, but I thought that was supposed to be restricted
to use by root (unless it's your control terminal....).

I think I just heard you say that was all malarkey, that anyone could
TIOCSTI my root session while logged in over a pty, and that you could
exploit those items to gain control of my session.

From the manual pages, I believe it shouldn't work.

If this is not true, I would like details. Not just "fixes", or
pontificating, but details. I can patch around lots of things, and replace
system code if necessary. Without some DETAILS it's difficult at best.

--

Tom Neff

unread,
May 2, 1991, 6:32:03 AM5/2/91
to
In article <11974:May214:00:36...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
> I again invite you and everyone else to stop
>spouting the same tired old rhetoric and start paying attention to this
>case on its own merits.

I suggest this invitation would not have been needed if 'brnstnd' had
been somewhat more professional in his original announcement. I can't
be the only one who found it a bit annoying.

If we really want to help the net, we should remember it's made up of
*people* who will have human reactions to what they read. It is, for
instance, pretty easy to apply 'need to know' criteria when people ask
for bug details, without going out of your way to trumpet the fact
beforehand and p*** people off unnecessarily in the process.

It's also a good idea to try and keep factual discussions of specific
security problems separate from editorializing about who ought to know
what, when, etc. There's already too much of a tendency to combine
these threads in ordinary followups. A new, primary posting that
deliberately combines security facts and editorializing is guaranteed to
fan the flames! And my point is that experienced posters can and should
know this up front. It's a question of how you want the discussion to
proceed. If you WANT to start a brawl, it's not hard to do. I don't
think the net is best served that way.

In this case it would probably have been enough to say "I seem to have
found a security bug in BSD ttys; the following vendors and versions are
known to be affected; the following are known to be OK; for further
details mail me at <address>." No big fuss, no cause celebre, just
quiet, effective response.

Karl Denninger

unread,
May 2, 1991, 3:53:05 PM5/2/91
to
In article <7363:May202:45:05...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
>If a vendor doesn't react by October 1992, its systems will be open to
>attack by any novice with rn and cc. Don't get the idea that I trust
>vendors to fix problems; I just want to give the more sensible ones a
>chance to clean up their act. I suspect that at least some will react.

You're giving them WAY too much slack.

I suggest 90 days. That's enough time to fix a hole of this magnitude and
ship tapes to anyone who needs them.

Then let 'em have it.

Of course, someone else might do it for 'ya too... (post the nasty code that
is).

Neil Rickert

unread,
May 2, 1991, 2:11:45 PM5/2/91
to
In article <8365...@bfmny0.BFM.COM> tn...@bfmny0.BFM.COM (Tom Neff) writes:
>In article <11974:May214:00:36...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> I again invite you and everyone else to stop
>>spouting the same tired old rhetoric and start paying attention to this
>>case on its own merits.
>
>I suggest this invitation would not have been needed if 'brnstnd' had
>been somewhat more professional in his original announcement. I can't
>be the only one who found it a bit annoying.

I didn't find anything annoying in the original announcement. I thought
Dan explained the situation quite clearly. Sure there was plenty of room
to disagree with some of his opinions, but it was easy to distinguish
fact from opinion.

>In this case it would probably have been enough to say "I seem to have
>found a security bug in BSD ttys; the following vendors and versions are
>known to be affected; the following are known to be OK; for further
>details mail me at <address>." No big fuss, no cause celebre, just
>quiet, effective response.

Sorry for the "grammatical" correction, but didn't you intend that last
sentence to read: No big fuss, no cause celebre, just quiet, INeffective
NONresponse.

Richard Tobin

unread,
May 2, 1991, 9:29:53 AM5/2/91
to
>I'd love to hear from anyone who can propose a simpler set of fixes
>that can still be proven to work.

While it seems likely that Dan's fixes are perfectly good, it wouldn't
be surprising if full discussion here led to further improvements (and
perhaps the discovery of other bugs). If vendors are (for once) going
to incorporate these changes it would be good to subject them to the
most rigorous scrutiny.

For this reason I believe it would be best for Dan to post full details
of the various loopholes.

-- Richard
--
Richard Tobin, JANET: R.T...@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.a...@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin

Jim Balter

unread,
May 1, 1991, 10:11:43 PM5/1/91
to
In article <13...@goofy.Apple.COM> e...@Apple.COM (Ed Carp) writes:

[idiotic garbage insulting Dan Bernstein and Gene Spafford]

I've seen plenty of rude and stupid Net postings, and am responsible for a few
myself, but this has got to be the most pointless I've seen. You've merely
guaranteed that you'll be the last to hear about this stuff, and made yourself
unpopular with a lot of people who have never heard of you before because,
unlike Dan and Gene, you have nothing to contribute. Dan has provided a large
amount of information and solutions, worked with developers, communicated with
others known to have knowledge in this area, and come up with a concrete plan
for solving the problem permanently. You may disagree with his particular
approach, but what could possibly make you think that you are in any way
*superior* to Dan, such that it could justify the arrogance of your post?
I suggest that you apologize and then find another line of work.

Dan Bernstein

unread,
May 2, 1991, 10:00:36 AM5/2/91
to
In article <7...@seqp4.UUCP> jda...@seqp4.ORG (Jeff d'Arcy) writes:
> The fact is that Dan would hardly be the first
> person to make such an offer without having the goods to back it up.

As Steve Bellovin, Gene Spafford, Tom Christiansen, various BSD folks
including Marc Teitelbaum and Keith Bostic, CERT, and a couple of other
people can attest, I *do* have the goods: a program that compiles, runs,
and breaks tty security sufficiently well to invisibly execute a command
under other people's sessions. I've had the program since before my
first article here about tty security a few years back, and it's
required only minor changes to work on systems through the latest BSD.
While in some alternate universe I might conceivably ``make such an
offer without having the goods to back it up,'' in reality I *do* have
what I have claimed.

That's the fact, Jeff. I again invite you and everyone else to stop


spouting the same tired old rhetoric and start paying attention to this
case on its own merits.

I don't expect to post further articles in this thread, as I find all
these counterfactual arguments remarkably counterproductive. I will
continue to watch for questions and complaints about the fixes, and if
necessary I will post comments about the security of specific machines.
In late 1992 we'll see how many vendors have woken up.

---Dan

Dave Hayes

unread,
May 1, 1991, 7:52:18 PM5/1/91
to
wrw...@rsi.UUCP (William Walker) writes:

>In article <1991Apr30....@jato.jpl.nasa.gov>, da...@jato.jpl.nasa.gov (Dave Hayes) writes:
>> I see what you are saying, but I have to disagree. Why has Dan even POSTED
>> that such holes exist, if he is not willing to disclose the details to
>> us system admins that are going to be of necessity interested in the problem?
> ^^^^^^^^^^^^^
>ok, so you *are* a system admin with a legit need to know. so what's the big
>deal with sending him a set of references??

I did. That didn't seem to help matters much. He claims I have no
legitimate reason to know. My paycheck claims differently.

>do you want every bored CS major between here and australia finding out
>about those holes a week or so before you get your patch tapes from the
>vendor?

What patch tapes from the vendor? We'll be damn lucky to see patches from
vendors in 1995! I don't trust vendors any farther than I can throw them,
see my previous stuff in comp.sys.apollo for a good example of that (about
the time of the HP buyout).

They have no incentive to fix these holes...yet. In that sense it would be
good for a few bored CS majors to get into it on the net...that'd make
everybody wake up and smell the coffee.

>so what do you do if you find a nifty little bug?? you tell the vendor
>and CERT, CERT makes it known to it's brain/talent trust, contacts the
>vendor who says "BFD". what about the guy *without* source?? how is
>he ever going to get the hole patched? unless the customers pressure
>the vendor,

Which rarely works anyway. What are you trying to say here?

>NO changes will ever be made unless it is the old "fixed
>in the next release" line, send us a check.... this "approval" arrangement
>also sounds kinda hokey to me, but i can't think of a better medium
>between leaving gaping holes under the carpet and posting potentially
>dangerous code on a public forum accessible to thousands of bored hacker
>wannabe's.

I don't know that posting the details of these hacks wouldn't do all of
us a lot of good...

These "approval" arrangements are always hokey. I personally believe
that this behaivor is something left over from childhood...8)

It's a cooperative universe. I help people all the time...if I was in
the same position, I'd want every other sysadmin to know exactly what
was broken and how to fix it (not just the latter).

And that's my $2e-02.

--
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ames!elroy!dxh

You possess only what will not be lost in a shipwreck.

Dan Bernstein

unread,
May 1, 1991, 10:58:51 PM5/1/91
to
In article <1991May1.2...@pcserver2.naitc.com> kden...@genesis.Naitc.Com (Karl Denninger) writes:
> 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.
[ 1. dynamic ptys, as on the RS/6000 ]

These are rather difficult to implement. They are an excellent long-term
solution, but it's much easier to apply my fixes to a typical BSD
machine than to radically reorganize and rewrite many parts of the
kernel for dynamic ttys.

[ 2. something with O_EXCL on the MIPS ]

Um, O_EXCL does not have the semantics you describe on a standard BSD
machine, nor on any of the variants with which I'm familiar. MIPS may
have added something to have O_EXCL pay attention to reference counts,
but that solution simply won't work under SunOS or Ultrix or any similar
system. (Of course, with my TIOCOPENCT you can simulate the same thing.)

---Dan

Dan Bernstein

unread,
May 1, 1991, 10:45:05 PM5/1/91
to
In article <13...@goofy.Apple.COM> e...@Apple.COM (Ed Carp) writes:
> In article <26844:May100:59:25...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Let me be more explicit. I consider vendors to have a legitimate
> Oh? I do consulting for a vendor, notably Apple.

Fine. So tell someone working on A/UX to get in touch with me.

> I also do consulting
> for a number of very large companies in the bay area, notably a very large
> public utility.

[ ... ]


> IMHO, your attitude is irrational. How many sites do I have to administer
> to qualify? One? Five? A hundred?

[ ... ]


> You haven't addressed the issue of whether I'm a cracker or not. Being a
> system administrator of a hundred systems doesn't prove you're a good guy,
> any more than being the administrator of one makes you a bad guy.

Somehow certain people have formed the mistaken impression that I have


been treating large sites differently from small sites. As I have tried
to explain, I do *not* see a fine line between the administrator of one
machine and the manager of a network of ten thousand machines. I have
not made and will not make a policy of sending break code to anyone who
asks---exactly *because* wide distribution of the code will eventually
reach the ``bad guys'', will affect practically every UNIX machine on
the Internet, and won't be traceable. So (as Dave Hayes can assure you)
I haven't been sending code to people merely because they manage a
``large enough'' network.

Would you like to reevaluate my ``irrational'' position, now that you
have some idea of what my position actually is?

> There's NO WAY that you're going to
> get all vendors to distribute fixes, let alone distribute them FOR FREE.

If a vendor doesn't react by October 1992, its systems will be open to


attack by any novice with rn and cc. Don't get the idea that I trust
vendors to fix problems; I just want to give the more sensible ones a
chance to clean up their act. I suspect that at least some will react.

I'd like to request once again that people read my articles before
spouting off about the proper distribution of security information. I
*have* posted fixes, not just complained about these holes. I have *not*
indicated that large sites are getting any special treatment, nor have I
been giving them any special treatment. I *have* set a date for
distributing code---a date far enough in the future that any concerned
vendor can fix its systems.

This may not be the optimal policy for handling a security hole, but
it's the best policy I've come up with, and I'm not going to listen to
complaints from people who can neither formulate a consistent
alternative policy nor think through its effects. The intelligent man
does not criticize what he cannot improve.

---Dan

Lawrence C Foard

unread,
May 2, 1991, 4:28:47 PM5/2/91
to
>In article <7...@seqp4.UUCP> jda...@seqp4.ORG (Jeff d'Arcy) writes:
>> The fact is that Dan would hardly be the first
>> person to make such an offer without having the goods to back it up.
>
>As Steve Bellovin, Gene Spafford, Tom Christiansen, various BSD folks
>including Marc Teitelbaum and Keith Bostic, CERT, and a couple of other
>people can attest, I *do* have the goods: a program that compiles, runs,
>and breaks tty security sufficiently well to invisibly execute a command
[rest deleted]

I agree:

With the information already posted here, it took me about 20 minutes to make
a program that could execute commands on other people terminals (80% of the
time spent in man). I briefly described how it worked to one of the people I
tested it on, they made a similar program by the time I walked across campus.

I think it is safe to assume that any one who has read this group and has
minimal unix programming knowledge could duplicate it easily.

Clearly security through obscurity isn't an option in this case.

One other possible attack occurs to me, and I don't think the fixs I have seen
posted would prevent it:

1) Make an unused tty device into your controlling terminal,
2) Close it.
3) You currently have no open files.
4) Wait for a victim to log in on the tty, open /dev/tty and use TIOCSTI on it.

Keith Muller

unread,
May 3, 1991, 6:11:10 AM5/3/91
to
In article <1991May2.2...@wpi.WPI.EDU>, ent...@wpi.WPI.EDU (Lawrence C Foard) writes:
> One other possible attack occurs to me, and I don't think the fixs I have seen
> posted would prevent it:
>
> 1) Make an unused tty device into your controlling terminal,
> 2) Close it.
> 3) You currently have no open files.
> 4) Wait for a victim to log in on the tty, open /dev/tty and use TIOCSTI on it.
If #4 restores access to a previous controlling terminal, then there is
a good arguement that the semantics of /dev/tty are broken (the fact you
have a tty listed as you controlling terminal should give you no special
access rights to it unless MAYBE you also have a current fd that references it).
I would tend to want an open of /dev/tty to always check the current
access to the controlling terminal.

Keith Muller
University of California
kmu...@ucsd.edu

Matthias Urlichs

unread,
May 3, 1991, 5:11:15 AM5/3/91
to
In alt.security, article <8365...@bfmny0.BFM.COM>,

tn...@bfmny0.BFM.COM (Tom Neff) writes:
< In article <11974:May214:00:36...@kramden.acf.nyu.edu> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
< > I again invite you and everyone else to stop
< >spouting the same tired old rhetoric and start paying attention to this
< >case on its own merits.
<
< I suggest this invitation would not have been needed if 'brnstnd' had
< been somewhat more professional in his original announcement. I can't
< be the only one who found it a bit annoying.
< [...]

< In this case it would probably have been enough to say "I seem to have
< found a security bug in BSD ttys; the following vendors and versions are
< known to be affected; the following are known to be OK; for further
< details mail me at <address>." No big fuss, no cause celebre, just
< quiet, effective response.

Unfortunately, real-world experience has shown too often that the most
likely reaction is that of a certain large flightless bird, sticking its head
into the sand.

Case in point: The reaction I encountered when discovering the first virus
(malicious) on a certain computer system. Manufacturer's reaction: "Due to
the open and documented nature of our architecture, ... viruses are ...
impossible on our machines".
Equivalent reaction from today, when confronted with Dan's tty holes: "We now
have POSIX sessions which are by definition a solution to all problems".
You can't argue with that mindset, you can only get out the largish hammer
and browbeat people into realizing that ignoring a problem doesn't make it go
away.

My non-solution was to write another virus which didn't do anything except
(a) to alert the user that it's present, and (b) to seek out the earlier
malicious virus and destroy it.
Dan's solution is to take said large hammer and wave it in a menacing way. I
am not exactly happy with this, but I sure can't think of a better way to get
the bugs fixed.

--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/

Marcus J. Ranum

unread,
May 2, 1991, 9:08:40 PM5/2/91
to
kden...@genesis.Naitc.Com (Karl Denninger) writes:
> brn...@kramden.acf.nyu.edu (Dan Bernstein) writes:
>>If a vendor doesn't react by October 1992, its systems will be open to
>>attack[...]

>
>You're giving them WAY too much slack.

I agree - that's giving the vendors a lot of slack. But, bear in
mind that not only are you (hopefully) going to embarrass vendors into
patching broken code - by posting the keys you are leaving a lot of sites
wide open to attack, sites that are not "guilty" and therefore deserve
some slack themselves.

This is a tricky issue, and it's not, I respectfully submit, as
simple as bashing a vendor.

mjr.

Dan Bernstein

unread,
May 3, 1991, 11:35:34 AM5/3/91
to
In article <1991May2.2...@wpi.WPI.EDU> ent...@wpi.WPI.EDU (Lawrence C Foard) writes:
>One other possible attack occurs to me, and I don't think the fixs I have seen
>posted would prevent it:
>1) Make an unused tty device into your controlling terminal,
>2) Close it.
>3) You currently have no open files.
>4) Wait for a victim to log in on the tty, open /dev/tty and use TIOCSTI on it.

My fixes stop this attack in three ways. First, by closing all open
files you prevent yourself from reopening the new /dev/tty. Technically,
you still do have the same controlling terminal (p_ttyd), but you can't
abuse that fact as the old /dev/tty driver is no longer accessible.
That's the point of replacing /dev/tty.

Second, you can't ``make an unused tty device into your controlling
terminal'' by opening an unused tty device, because all unused tty
devices are world-inaccessible. That's the point of protecting the files
and making the tty-handling programs setuid pty.

Third, you can't ``make an unused tty device into your controlling
terminal'' by waiting for your ctty to become unused, because the
tty-handling process keeps the master side open until nobody has the
slave side open. That's the point of TIOCOPENCT. Note that without the
new /dev/tty this protection would not be effective.

There are more sophisticated attacks that are only stopped by one of
these three measures.

---Dan

Matthew Ender

unread,
May 2, 1991, 8:35:04 PM5/2/91