brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/26/91)
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 cert@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 bostic@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
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (04/28/91)
In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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}'` subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
erc@Apple.COM (Ed Carp) (04/29/91)
In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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? 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 erc@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! --robs@ux1.cso.uiuc.edu (Rob Schaeffer) -- Absolutely unabashed Gates McFadden groupie! --
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (04/30/91)
erc@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: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910
kdenning@pcserver2.naitc.com (Karl Denninger) (04/30/91)
In article <13218@goofy.Apple.COM> erc@Apple.COM (Ed Carp) writes: >In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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. -- 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.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/30/91)
In article <13218@goofy.Apple.COM> erc@Apple.COM (Ed Carp) writes: > In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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
smb@ulysses.att.com (Steven Bellovin) (04/30/91)
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. 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
kdenning@pcserver2.naitc.com (Karl Denninger) (04/30/91)
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.
russotto@eng.umd.edu (Matthew T. Russotto) (05/01/91)
In article <1991Apr29.222139.21284@pcserver2.naitc.com> kdenning@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 russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
dave@jato.jpl.nasa.gov (Dave Hayes) (05/01/91)
erc@Apple.COM (Ed Carp) writes: >In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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? 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 dave@elxr.jpl.nasa.gov dave@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@jato.jpl.nasa.gov (Dave Hayes) (05/01/91)
smb@ulysses.att.com (Steven Bellovin) writes: >In article <1991Apr29.222139.21284@pcserver2.naitc.com>, kdenning@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. -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@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."
kdenning@pcserver2.naitc.com (Karl Denninger) (05/01/91)
In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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. >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. -- 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.
rickert@mp.cs.niu.edu (Neil Rickert) (05/01/91)
In article <1991Apr30.224740.17040@pcserver2.naitc.com> kdenning@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 <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
sef@kithrup.COM (Sean Eric Fagan) (05/01/91)
In article <1991Apr30.231235.7874@mp.cs.niu.edu> rickert@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; sef@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.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/01/91)
In article <1991Apr30.164646.11693@pcserver2.naitc.com> kdenning@pcserver2.naitc.com (Karl Denninger) writes: > In article <14683@ulysses.att.com> smb@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
scs@lokkur.dexter.mi.us (Steve Simmons) (05/01/91)
smb@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. kdenning@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
kdenning@genesis.Naitc.Com (Karl Denninger) (05/01/91)
In article <1991Apr30.231235.7874@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1991Apr30.224740.17040@pcserver2.naitc.com> kdenning@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. -- 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.
jkp@cs.HUT.FI (Jyrki Kuoppala) (05/01/91)
In article <1991Apr30.164646.11693@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
russotto@eng.umd.edu (Matthew T. Russotto) (05/02/91)
In article <1991Apr30.224740.17040@pcserver2.naitc.com> kdenning@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? -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/02/91)
In article <1991May1.010657.281@lokkur.dexter.mi.us> scs@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
jdarcy@seqp4.ORG (Jeff d'Arcy) (05/02/91)
kdenning@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.
wrwalke@rsi.UUCP (William Walker) (05/02/91)
In article <1991Apr30.224235.2459@jato.jpl.nasa.gov>, dave@jato.jpl.nasa.gov (Dave Hayes) writes: > smb@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... wrwalke@rsi.prc.com -- PRC, a wholly owned subsidiary of Black+Decker Inc. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
erc@Apple.COM (Ed Carp) (05/02/91)
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 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 erc@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! --robs@ux1.cso.uiuc.edu (Rob Schaeffer) -- Absolutely unabashed Gates McFadden groupie! --
kdenning@genesis.Naitc.Com (Karl Denninger) (05/02/91)
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.
kdenning@genesis.Naitc.Com (Karl Denninger) (05/02/91)
In article <1991May1.170641.17086@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1991Apr30.224740.17040@pcserver2.naitc.com> kdenning@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 - 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.
sblair@upurbmw.dell.com (Steve Blair) (05/02/91)
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 erc@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 sblair@upurbmw.dell.com ================================================================
dave@jato.jpl.nasa.gov (Dave Hayes) (05/02/91)
wrwalke@rsi.UUCP (William Walker) writes: >In article <1991Apr30.224235.2459@jato.jpl.nasa.gov>, dave@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 dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh You possess only what will not be lost in a shipwreck.
jim@segue.segue.com (Jim Balter) (05/02/91)
In article <13218@goofy.Apple.COM> erc@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.brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/02/91)
In article <13266@goofy.Apple.COM> erc@Apple.COM (Ed Carp) writes: > 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 > 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
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/02/91)
In article <1991May1.201408.16204@pcserver2.naitc.com> kdenning@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
tneff@bfmny0.BFM.COM (Tom Neff) (05/02/91)
In article <11974:May214:00:3691@kramden.acf.nyu.edu> brnstnd@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.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/02/91)
In article <721@seqp4.UUCP> jdarcy@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
rickert@mp.cs.niu.edu (Neil Rickert) (05/03/91)
In article <83658694@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >In article <11974:May214:00:3691@kramden.acf.nyu.edu> brnstnd@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. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kdenning@genesis.Naitc.Com (Karl Denninger) (05/03/91)
In article <7363:May202:45:0591@kramden.acf.nyu.edu> brnstnd@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). -- 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.
entropy@wpi.WPI.EDU (Lawrence C Foard) (05/03/91)
In article <11974:May214:00:3691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <721@seqp4.UUCP> jdarcy@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.
dave@jato.jpl.nasa.gov (Dave Hayes) (05/03/91)
brnstnd@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 dave@elxr.jpl.nasa.gov dave@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.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (05/03/91)
kdenning@genesis.Naitc.Com (Karl Denninger) writes: > brnstnd@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.
muller@sdcc10.ucsd.edu (Keith Muller) (05/03/91)
In article <1991May2.202847.15537@wpi.WPI.EDU>, entropy@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 kmuller@ucsd.edu
jdarcy@seqp4.ORG (Jeff d'Arcy) (05/03/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein): >In article <721@seqp4.UUCP> jdarcy@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: That's a very nice piece of name-dropping there, but the fact remains that we mere mortals have no evidence of your claims. I have no reason to think this program will work on either of the systems I've worked on and, since I can't get a copy of the program without major headaches (despite the fact that I'm a professional kernel developer in as good a position as anyone to fix the bugs on both platforms), I just won't bother. Maybe I would if I had time, but I'm plenty busy without having to take any Bernstein bullshit. >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. Its own what? I see this as just another plea for attention by the net's most infamous glory-hound. The real hackers already know about this bug, and many others that I'm sure neither you nor I have figured out yet. I've seen several generations of pty-related security problems before you came along, and there will undoubtedly be more after your current crusade is only a memory. All your crowing about your intellectual and moral superiority won't get you the respect you so obviously crave. Your "amazing discoveries" are pretty mundane to those of us who make a living at this stuff. >I don't expect to post further articles in this thread I wish I could believe you. -- Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4@m2c.org> Time flies like an arrow; fruit flies like a banana
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/03/91)
In article <1991May2.202847.15537@wpi.WPI.EDU> entropy@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
ian@pharaoh.UUCP (Ian Crocker) (05/03/91)
Maybe I am missing something here but I don't see where the security issue lies. Sure it is easy to knock up a program that disassociates itself from the controlling tty using TIOCNOTTY, then attach to another tty that you have write permission on. However when you try and do the TIOCSTI it fails on all the systems I have tried it on because you are not the owner of the device. I know that the manual says it should work as you are trying to do the ioctl on your control terminal, but this is not the case on my systems - you have to own the device or have an euid of 0. Ian. -- Ian Crocker NPW-mail : ian@pharaoh usenet : ian@cyborg.bt.co.uk
ian@pharaoh.UUCP (Ian Crocker) (05/03/91)
In article <438@pharaoh.UUCP>, ian@pharaoh.UUCP (Ian Crocker) writes: > > write permission on. However when you try and do the TIOCSTI it fails on > all the systems I have tried it on because you are not the owner of the > device. I know that the manual says it should work as you are trying > to do the ioctl on your control terminal, but this is not the case on my > systems - you have to own the device or have an euid of 0. > Further to my previous post I thought of a machine I hadn't tried it on and sure enough it worked. Complete control of the root terminal from an unprivileged userid. Seems this manufacturer is lagging behind the others - no prizes for guessing who it is! Ian. -- Ian Crocker NPW-mail : ian@pharaoh usenet : ian@cyborg.bt.co.uk
jfh@greenber.austin.ibm.com (John F Haugh II) (05/04/91)
In article <18954@sdcc6.ucsd.edu> muller@sdcc10.ucsd.edu (Keith Muller) writes: >In article <1991May2.202847.15537@wpi.WPI.EDU>, entropy@wpi.WPI.EDU (Lawrence C Foard) writes: >I would tend to want an open of /dev/tty to always check the current >access to the controlling terminal. The current implementations of /dev/tty don't cause the open to go through the filesystem. Nor would that always be possible - the "current access" can be completely meaningless if there are more than one (or even none) instances of that device. One of the advantages of "POSIX-like" tty subsystems is that /dev/tty operations can be restricted by "session id". Dan can tell you what is wrong with how POSIX works with regard to this feature ... -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
fitz@mml0.meche.rpi.edu (Brian Fitzgerald) (05/05/91)
Gentlemen: - Please - This is another plea for restraint and courtesy. Some of us follow alt.security mainly to learn. IMHO, personal insults do not belong in this newsgroup. Thank you. Brian
jkp@cs.HUT.FI (Jyrki Kuoppala) (05/05/91)
In article <438@pharaoh.UUCP>, ian@pharaoh (Ian Crocker) writes: [TIOCNOTTY] >However when you try and do the TIOCSTI it fails on >all the systems I have tried it on because you are not the owner of the >device. I know that the manual says it should work as you are trying >to do the ioctl on your control terminal, but this is not the case on my >systems - you have to own the device or have an euid of 0. Hmm, I haven't checked lately and am not sure if I remember it correctly but are you sure after attaching to another tty you did open ("/dev/tty", O_RDWR) and then the TIOCSTI on that file descriptor ? That worked on a pretty generic bsd 4.3 system at least a couple of years ago. //Jyrki
jfh@rpp386.cactus.org (John F Haugh II) (05/06/91)
In article <729@seqp4.UUCP> jdarcy@sequoia.com (Jeff d'Arcy) writes: >brnstnd@kramden.acf.nyu.edu (Dan Bernstein): >>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: > >That's a very nice piece of name-dropping there, but the fact remains that we >mere mortals have no evidence of your claims. Given that many of those people read this newsgroup, you don't have to verify his claims. Tom Christiansen regularly reads this group, along with Steve Bellovin. Perhaps they can verify what Dan is saying (they already have from what I've seen). Dan may be pompous and long winded, but he certainly isn't a fool or a liar. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (05/06/91)
From: jdarcy@seqp4.ORG (Jeff d'Arcy) >That's a very nice piece of name-dropping there, but the fact remains that we >mere mortals have no evidence of your claims. I have no reason to think this >program will work on either of the systems I've worked on and, since I can't >get a copy of the program without major headaches (despite the fact that I'm a >professional kernel developer in as good a position as anyone to fix the bugs >on both platforms), I just won't bother. Maybe I would if I had time, but I'm >plenty busy without having to take any Bernstein bullshit. From: ian@pharaoh.UUCP (Ian Crocker) >Further to my previous post I thought of a machine I hadn't tried it on and >sure enough it worked. Complete control of the root terminal from an >unprivileged userid. Seems this manufacturer is lagging behind the others - >no prizes for guessing who it is! Sequoia Systems? After all, they're too busy to check. /pbp -- Paul Pomes, Computing Services Office University of Illinois - Urbana
tchrist@convex.COM (Tom Christiansen) (05/07/91)
From the keyboard of jfh@rpp386.cactus.org (John F Haugh II): :>That's a very nice piece of name-dropping there, but the fact remains that we :>mere mortals have no evidence of your claims. : :Given that many of those people read this newsgroup, you don't have to :verify his claims. Tom Christiansen regularly reads this group, along :with Steve Bellovin. Perhaps they can verify what Dan is saying (they :already have from what I've seen). Dan's program does indeed compromise ConvexOS 9.0; I will vouch for no other system. (There's something terribly ironic about me having Dan for a customer, eh? :-) We've closed up the hole at least for rlogin, telnet, and xterm for the 9.1 release. It required a kernel change, so there aren't patched versions of these programs available. The script and window utilities will still be insecure as they can't chown and chmod their ttys. I'm personally hoping for a more complete long-term solution using a session manager, but there's no way to anticipate if or when this might occur. I think anybody who's been working on this stuff for a while already knows the scoop about the particular hole we've all been dancing around here. One poster mentioned he'd gotten working code exploiting the problem in about 20 minutes. That means the crackers can, too, and have probably already done so. The signal-to-noise ratio in this discussion is discouraging. Insults aren't going to buy anyone anything. They will neither persuade someone to your cause who was on the other side, nor do they invalidate Dan's working code, nor (I imagine) will they stop him from posting details a child (as opposed to professionals, who already understand) could follow come October. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "So much mail, so little time."
bombman@diku.dk (Hans-Henrik St{rfeldt) (05/09/91)
dave@jato.jpl.nasa.gov (Dave Hayes) writes: >erc@Apple.COM (Ed Carp) writes: >>In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@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? >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! Interesting, i would just LOVE! to see your face, when some novice user make an 'rm -Rf /*' when YOU log in as root.... Huh?! i see you come from a '*.nasa.gov' i BET there is something secret there... somewhere... >-- >Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA >dave@elxr.jpl.nasa.gov dave@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." --Hans Henrik Staerfeldt ..The novice user.. -- ____________________________________________________________ DK_ | | Bombman the mad bomber | // .|{}| Bombman@freja.diku.dk | /-| |__| Hans Henrik Staerfeldt |
jdarcy@seqp4.ORG (Jeff d'Arcy) (05/10/91)
Paul-Pomes@uiuc.edu: > From: ian@pharaoh.UUCP (Ian Crocker) > >>Further to my previous post I thought of a machine I hadn't tried it on and >>sure enough it worked. Complete control of the root terminal from an >>unprivileged userid. Seems this manufacturer is lagging behind the others - >>no prizes for guessing who it is! > >Sequoia Systems? After all, they're too busy to check. This post gave me the incentive to check things out under TOPIX (Sequoia's UNIX-compatible OS) despite the fact that I'll probably get in trouble for taking the time away from my assigned tasks to do so. What I found was a very serious security bug involving TIOCSTI, but I don't think it's the same one people have been talking about here. It doesn't bother me to admit that the problem exists because: (a) I've barely been at Sequoia long enough to remember my boss's name, let alone take responsibility for day-one bugs; and (b) the existence of the problem in TOPIX does nothing to invalidate any of my earlier statements. Now it's on my list of things to fix. Big deal. Except for the publicity, there's nothing to distinguish this bug from the sort of stuff that I and thousands of other OS developers at dozens of companies have seen every day for years. Maybe Dan, Ian, and Paul's excitement can be explained by the observation that just about anything is exciting the first few times. Believe me, kids: there are dozens of bugs in *every OS in the world* that would horrify users and administrators alike if they were ever made known. Twiddle this, frobnicate that, and...BLAM...instant super-user, or system crash, or filesystem corruption, or whatever. Should I tell you about the SOCK_RAW crashes at one vendor, or the disappearing disk space at another, or the setuid bug at a third? Really, I got a million of 'em. Why don't you guys stop crowing because you found *one* bug in *one* OS, and think a little about how many you *don't* know about and never will? I'm sure there are plenty of scary bugs that I'll never hear about because they were fixed by my predecessors. Excuse me. I have bugs to fix. -- Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4@m2c.org> Time flies like an arrow; fruit flies like a banana
dave@jato.jpl.nasa.gov (Dave Hayes) (05/10/91)
bombman@diku.dk (Hans-Henrik St{rfeldt) writes: >Interesting, i would just LOVE! to see your face, when some novice user >make an 'rm -Rf /*' when YOU log in as root.... I'm sure you aren't as interested as Mr. Bernstein would be. -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh If your own vice happens to be the search for virtue, recognize that it is so.
mbk@jacobi.ucsd.edu (Matt Kennel;I11 CMRR;534-4511) (05/10/91)
jfh@rpp386.cactus.org (John F Haugh II) writes: > > Dan may be pompous and long winded, but he certainly isn't a fool or > a liar. I can assert that I've seen (ok ok, been the victim :-) ) of Dan's tty mangling programs--I believe the problems are real. On the other hand, nothing he inflicted on me ever seemed more capable than just being an irritant. > John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Matt Kennel mbk@inls1.ucsd.edu
dsmythe@netcom.COM (Dave Smythe) (05/12/91)
Regarding the TIOCSTI problem, I can verify that it is real. It took about 20 minutes of poking around in man pages and that was it. For reference, I was able to reproduce the problem in SunOS 4.0.3 and 3.5, but not in 4.1. D
smb@ulysses.att.com (Steven Bellovin) (05/14/91)
The bug, or rather, bugs, that Dan is talking about do indeed exist, in many versions of the UNIX system. The root problem is that access to the user's tty is not adequately controlled. There are a number of manifestations of this problem; some are entirely innocent but annoying nevertheless. For every such manifestation, there has been an attempted fix over the years, it seems. Few have been notably successful; problems (including security problems) still show up. I won't recite here all of the issues; they're described at some length in my paper. (Btw, for those who are interested but haven't been able to locate a copy of the relevant Usenix proceedings, I've made the paper available for ftp on research.att.com, in dist/sessext.ps.Z) This problem has been bothering me for quite a number of years; I remember investigating it as early as 1979. I concluded that much of the problem was due to complexity -- it wasn't possible to revoke access in any clean, comprehensive fashion because the necessary information was spread out into too many different places. Furthermore, even if I did all the work necessary -- chasing down u.u_ttyp, looking for vagrant file descriptors pointing to a given tty, blocking race conditions, etc. -- I realized that I'd never feel confident that I'd found them all. Witness vhangup() -- for all its deficiencies, it is capable of doing much of the job, but there have been several application patches released over the years because there were unappreciated subtleties to the proper usage of the system call. What was needed, then, was not just a solution, but one that was demonstrably correct. (By ``correct'', btw, I mean that it accomplished my goals: that it unconditionally revoked all prior access to the tty.) The other focus of my work was the hangup/DTR problem. Many versions of the UNIX system could experience race conditions involving hangup. Perhaps the login shell would hang around waiting for a buggy application to finish, or some nohup'ed application still had some fd's open, so the close routine was never called. Or maybe there was another scenario -- I suspect that if all variations of the problem were ever identified, the problem might have been solved. But it wasn't. The manifestations were dead ports -- modems that didn't answer, or network daemons that tried to talk on wedged ptys. The two threads are tied together in hangup processing. Apart from getting the line properly re-enabled, the receipt of a hangup signal is when you really have to revoke access to the tty -- that's when the hardware or the network daemon have concluded that the connection no longer exists. But you can't call a close routine then -- HUP signals occur at interrupt time, and hence without a user context. The upshot of all that was the session manager. I implemented it for System V because streams and multiplexor devices provided a clean implementation technique. But I could have done it for 4.2bsd; I had an implementation sketched out around 1984 or thereabouts. I'm not claiming that my idea is the only way to do things, or even necessarily the best. But its complexity is all in one place (the user-level session manager process), and the kernel implementation was such that it would tend to ``fail secure'', as it were. I'm somewhat leary of Dan's solution because I think it's too complex in the wrong spots -- it puts too much of the onus on application programs (which one would like to have unprivileged, i.e., the script command). Keith Muller's generation number idea sounds intriguing, but I haven't analyzed it fully. In any event, it wouldn't solve the DTR problem. John Haugh's suggestion of a secure attention key tends to beg the point -- one can specify one, but there's still the problem of how you implement it. It's still hard to revoke all access to an open tty, especially given the indirect accesses through /dev/tty. (Obviously it can be done without the session manager, since several vendors have done it. I haven't examined any of these in detail, so I don't know how reliable their solutions are.) I'm *not* prepared to offer my own retrofit solution at this time. --Steve Bellovin
jfh@rpp386.cactus.org (John F Haugh II) (05/14/91)
In article <14768@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: > John Haugh's >suggestion of a secure attention key tends to beg the point -- one can >specify one, but there's still the problem of how you implement it. I don't think this is even a problem. This issue with SAK implementation seems to be a trade-off between knowing it will always work, and wanting it to always work. The issue seems to be solved by having fixed-baud ports use fixed-key sequences that are unlikely to occur in real life, and having variable-baud ports use baud rate independent sequences (such as framing errors, hence Dan's <BREAK> key suggestion). If you allow it to always work, you have the problem I pointed out in the discussion with Dan - what do you do when something mimics the <BREAK> key, such as a framing error condition on a serial port. If you allow just anyone to turn it off, you get no assurance that whacking the SAK key really got you on the trusted path. Thus there is a struggle between security and usablity ... >It's still hard to revoke all access to an open tty, especially given >the indirect accesses through /dev/tty. (Obviously it can be done >without the session manager, since several vendors have done it. I >haven't examined any of these in detail, so I don't know how reliable >their solutions are.) I'm *not* prepared to offer my own retrofit >solution at this time. I wouldn't say it is "hard", simply as part of the nature of the beast, but rather it is "hard" because the information isn't collected in the right places (which you seem to allude to). There is no mapping from inode to process, and there is no easy collection of u_ttyd's all in one nice place. Fix those two problems, and the issue should evaporate. I do know that AT&T has managed to solve the problems with access revocation since their new MLS product is either been evaluated at B2 or is heading that way (their original MLS has already been through formal at B1). For IBM's current offering, AIX v3 has revoke() and frevoke() system calls which provide for all the needed assurance that you have a clean line, when combined with fchown() and fchmod(). As for "how reliable they are", in the case of the former, the NCSC has blessed it, and in the later, one customer found the notion of clean ports disgusting enough (I made sure the login port was really, really clean ;-) that we were forced to take out the code that made scrubbing the port prior to login mandatory. But it is very possible under Sys5/MLS and AIX v3 to get completely clean ports, without the changes Dan suggests are required. I know that the IBM, Apple, Sun, and SCO UNIX (as well as IBM's old Trusted XENIX) products all provide assurances that what you are talking is really what you think you are talking to, and that no one else has access to it. That is just the partial list ... -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/15/91)
In article <732@seqp4.UUCP> jdarcy@sequoia.com (Jeff d'Arcy) writes: > Now it's on my list of things to fix. Big deal. Except for the publicity, > there's nothing to distinguish this bug from the sort of stuff that I and > thousands of other OS developers at dozens of companies have seen every day > for years. Maybe Dan, Ian, and Paul's excitement can be explained by the > observation that just about anything is exciting the first few times. Maybe I found it exciting when I first found it and announced it a few years back, but by now it's simply tedious to see each vendor introduce one kludge after another, each of which is supposed to solve the problem and none of which actually does. > Believe me, kids: there are dozens of bugs in *every OS in the world* that > would horrify users and administrators alike if they were ever made known. Look, kid, I'm sure we all know our share of holes in each system. Holes that crash the machine, holes that aren't auditable, holes that break root, holes that have been known and complained about for years. But how many of those holes appear in over a million machines from dozens of vendors? How many of them have been ``fixed'' in at least nine different ways---five separate times in one system alone? This is not a minor problem, and it's not going to magically disappear. Most holes only appear in one system at a time, and are fixed rather quickly. To exploit this one I can run essentially the same code on week-old releases from all the major vendors as I had years ago. So can anyone else. Get a sense of perspective, Jeff! ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/15/91)
In article <19271@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > I do know that AT&T has managed to solve the problems with access > revocation since their new MLS product is either been evaluated at B2 While this is a good indicator of security, it cannot be considered entirely accurate---apparently the ratings are based on tests rather than specifications, and one of the NCSC reviewers told me that he hadn't heard of the tty security problems (hence couldn't test them). > As for "how reliable they are", in the case of the former, the NCSC > has blessed it, See above. > I know that the IBM, Apple, Sun, > and SCO UNIX (as well as IBM's old Trusted XENIX) products all provide > assurances that what you are talking is really what you think you are > talking to, and that no one else has access to it. I don't have firsthand experience with the UNIX products from IBM and Apple, but Sun has never successfully closed the tty security holes. Comments from others indicate that A/UX is just as insecure. I've only been talking about BSD-derived systems so I don't want to discuss SCO in detail, but I'm told that it may have similar problems with /dev/tty. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/16/91)
In article <14768@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: [ about his session manager ] > But its complexity is all in one place (the user-level > session manager process), and the kernel implementation was such that > it would tend to ``fail secure'', as it were. I'm somewhat leary of > Dan's solution because I think it's too complex in the wrong spots -- > it puts too much of the onus on application programs (which one would > like to have unprivileged, i.e., the script command). I have to agree with this. I find it absolutely ridiculous that so many different programs---telnetd, rlogind, script, emacs, xterm, expect, screen, mtty, Randal's chat2.pl, atty, etc.---are all responsible for managing a single resource. If even one of those programs fails, the whole system will fail. This *is* way too complex in the wrong spots. My previous solution to this problem was pty, my generic pseudo-tty session manager. Every single one of those programs can be modified to use pty---script, for example, becomes a tiny (unprivileged) shell script as included in the pty package. You can change the entire pseudo-tty interface by just changing that one program. In this respect pty is a lot like Bellovin's session manager (which it was partially modelled after). The problem is that it's hard to convince people to stop copying the pseudo-tty allocation code from one application to the next, and to use pty instead. If I thought people would accept this solution, then I'd gladly reorganize my tty fixes around pty, and Bellovin's objection would disappear. But people don't seem to understand why session managers---either Bellovin's or mine---are so useful. So I have no choice but to work within the existing complexity of the tty subsystem. (Side note: Remember that telnetd/rlogind patch announced by CERT? Well, at least under SunOS 4.0.3 and later as well as some other systems, pty will skip a tty with ``/dev/ttyp7 unopenable: I/O error'' in the same situations where Sun's new telnetd/rlogind will skip it. So anyone who's been using pty since last year is already safe against ``cover''. Is that any incentive to start using it?) ---Dan
jfh@rpp386.cactus.org (John F Haugh II) (05/16/91)
In article <1775:May1420:06:1291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >While this is a good indicator of security, it cannot be considered >entirely accurate---apparently the ratings are based on tests rather >than specifications, and one of the NCSC reviewers told me that he >hadn't heard of the tty security problems (hence couldn't test them). The test cases are usually fairly exhaustive. The test suite for access() on IBM Secure Xenix had something like 1300 different tests that it performed. I coded some of the early tests for the revoke() and frevoke() system call while AIX v3 was in development, and access via /dev/tty was (as I recall, it's been 2 years now) one of the things I covered. I do know that backgrounded processes die painful deaths; customers weren't too pleased to see their jobs bite the big one, even when they were launched with nohup and so on. Talking about bugs in the specific sense ("do you know about TSTI") and having your NCSC reviewer stare back out you is not proof that the Orange Book requirement that the system provide for resource reuse where all previous, unauthorized accesses to the resource have been terminated. Given that object reuse is part of the specification for a secure system, I'd say you have some misconception about what the rating for a secure system entails. That doesn't mean there aren't bugs, but it certainly doesn't mean that access after logout isn't one of the criteria that are examined. AIX v3 originally handled it by killing every process that was anywheres near a tty device. Not exactly a popular approach, but it worked great ;-) >> As for "how reliable they are", in the case of the former, the NCSC >> has blessed it, > >See above. See above. These aren't little programmer weenies who don't know how UNIX works. This is why features like access revocation exist in the first place - think of all the ways you can get access to a device. Now think of a way to revoke all those ways. There are only so many system calls, it shouldn't be that hard to figure out which ones affect tty access. >I don't have firsthand experience with the UNIX products from IBM and >Apple, but Sun has never successfully closed the tty security holes. >Comments from others indicate that A/UX is just as insecure. I've only >been talking about BSD-derived systems so I don't want to discuss SCO in >detail, but I'm told that it may have similar problems with /dev/tty. I suspect that every system with some "revoke" concept doesn't have problems with its tty system. You scheme, for example, can't insure the passwd command that it isn't being run as part of a trojan horse. Mine can. Waving "physical security" at the problem doesn't free you of your responsiblity for "software security" either. This is why "Trusted Path" and "SAK" and "access revocation" are so much more useful than "don't ever let anyone talk to the hardwire tty." What can you do to prevent the trojan from ever being run, and once it is running, how can you get rid of it? -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
mrm@sceard.Sceard.COM (M.R.Murphy) (05/17/91)
In article <19280@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: [...] > >See above. These aren't little programmer weenies who don't know >how UNIX works. This is why features like access revocation exist >in the first place - think of all the ways you can get access to >a device. Now think of a way to revoke all those ways. There are >only so many system calls, it shouldn't be that hard to figure out >which ones affect tty access. > Not when the number of system calls increases faster than you can read about 'em. This is not intended as a flame at jfh. It's a broad flame at lots of folks, me included, sometimes. I know that thinking about all the security stuff is fun. It also is or can be lucrative. Think of it as welfare for computer dweebs. But sometimes, just sometimes, I wish that I could use my home system for crystal structure refinement without all that security crap getting in my way. I also wonder from time to time how much of the security software, no, amend that to system software in general comes from people who, even if they RTFM, don't UTFM and certainly don't understand the philosophy behind TFM. You'd hope, if they did, that the solutions would be a whole lot simpler. Or wouldn't be needed in the first place. Oh, well. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/20/91)
In article <19280@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > I suspect that every system with some "revoke" concept doesn't have > problems with its tty system. BSD 4.2- and 4.3-derived systems have a ``revoke'' concept (viz., vhangup()) and have huge problems with the tty system. So much for that suspicion. The very latest version of BSD has a revoke() syscall which works just like you said. It still lets anyone take over a ``script'' session. Why do you have this religious fixation on revoke()? In contrast, the SVR4 tty system allocates ttys dynamically (in the sense that you get a tty that nobody else is using, not in the sense that there are arbitrarily many ttys). It doesn't revoke() anything; it just skips what's being used. The BSD 4.4 tty system will also have dynamic tty allocation. So will a future SunOS release. C'mon, John, why can't you point out the insecurity in SVR4 ttys? If, as you claim, skipping what's in use is so much less secure than attempting to revoke what's in use, then where's the attack that Steve Bellovin and Jonathan Shapiro somehow missed? Where's the danger? > You scheme, for example, can't insure > the passwd command that it isn't being run as part of a trojan horse. > Mine can. Bullshit. Have you ever heard of network logins? Have you ever heard of dialout modems? As I said before, unless you restrict use of passwd to the console, passwd will have absolutely no idea what it's talking to. Your claim is never true. Face it, John: revoke() does not solve any problems that avoiding a used tty entirely doesn't solve. The most revoke() can do is guarantee that the tty used for login is clean, and that's exactly what my proposals do. Stop pretending that there's some advantage to revoke(). > This is why > "Trusted Path" and "SAK" and "access revocation" are so much more > useful than "don't ever let anyone talk to the hardwire tty." So how come UNIX processes don't choose their own pids and revoke access by any other processes with the same pid? How come pid revocation isn't ``so much more useful'' than dynamic process allocation? How about memory use? How about inodes? How about pipes? How about disk space? Dynamic allocation appears everywhere in UNIX. It works. Access revocation is a pointless complexity. > What > can you do to prevent the trojan from ever being run, and once it is > running, how can you get rid of it? A Trojan Horse is ineffective unless it actually gets a chance to talk to someone. Under my suggestions, a normal user logging in will always be talking directly to a system process. No other processes can access the line. There's no reason to ``get rid of'' what you can just ignore. ---Dan
jfh@rpp386.cactus.org (John F Haugh II) (05/20/91)
In article <29167:May1918:13:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >BSD 4.2- and 4.3-derived systems have a ``revoke'' concept (viz., >vhangup()) and have huge problems with the tty system. So much for that >suspicion. Then they obviously did it incorrectly. UNIX also has the concept of access right restrictions implemented via the iaccess() kernel service. If it had a bug allowing "jfh" to read and write any files owned by "root", it wouldn't disprove the concept of file access permissions. It would merely prove that the implementors of BSD didn't get vhangup() correct (if you want to claim its purpose is really to completely clean a line, that is). >The very latest version of BSD has a revoke() syscall which works just >like you said. It still lets anyone take over a ``script'' session. This has =nothing= to do with the discussion. 1). Does the revoke system call work? 2). Does the system protect the cleaned port from intrusion? If 1) and 2) are both true, and you can still take over the "script" session, I'll eat my shorts. Unless the revoke() system call removes all access to the port, and unless the system changes the access modes of the cleaned tty line to deny future attempts at accessing the system, there is no guarantee the line is protected. >Face it, John: revoke() does not solve any problems that avoiding a used >tty entirely doesn't solve. The most revoke() can do is guarantee that >the tty used for login is clean, and that's exactly what my proposals >do. Stop pretending that there's some advantage to revoke(). Sure there are. "Denial of service". If I manage to take up all the pty's, how are you ever going to get me off the port? Besides, the point about revoke() isn't to keep you from using a tty that is =in= use, but rather to get a program that has no business using the port off the port in the first place. That could be anything - including killing jobs that attached themselves to your port =after= you logged in. How do you get a job that has gained read/write access to your login port off of your login port once it is on there? >A Trojan Horse is ineffective unless it actually gets a chance to talk >to someone. Under my suggestions, a normal user logging in will always >be talking directly to a system process. No other processes can access >the line. There's no reason to ``get rid of'' what you can just ignore. I don't care what happens when you login. I want to know what happens =after= you login. Get it through you think skull. I don't care about login time. F*ck login time. What happens 15 or 20 minutes later when some proceess some how gets on your port and starts doing things to it? How does the Dan Bernstein Trusted Path Manager get that process off the line, other than arguing with it for 2 weeks before doing nothing? -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/22/91)
In article <19315@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > >Face it, John: revoke() does not solve any problems that avoiding a used > >tty entirely doesn't solve. The most revoke() can do is guarantee that > >the tty used for login is clean, and that's exactly what my proposals > >do. Stop pretending that there's some advantage to revoke(). > Sure there are. "Denial of service". If I manage to take up all > the pty's, how are you ever going to get me off the port? If a user opens all the ptys (which he can't under my proposal since they're protected), nobody will be able to open any of them again, and revoke() doesn't do diddly about that. If a user has access to all the ttys, then under my proposal not only will all those ttys will be accounted to him, but he'll have to be running under a telnetd or rlogind or whatever on each port, so all the ptys will be open anyway. Once again revoke() does absolutely nothing. > I don't care what happens when you login. I want to know what happens > =after= you login. Get it through you think skull. I don't care about > login time. F*ck login time. It's too bad you feel that way. Right now I'm focusing on tty security, and each login process runs under a tty. (This isn't how it should be: you should allocate as few resources as possible to someone who hasn't idenitifed himself. Wasting an entire tty is silly.) If the line is clean before login runs, it will remain clean unless the user does something stupid, like find / -user `whoami` -exec chmod {} 666 \;. > How does the Dan Bernstein Trusted Path Manager get that process off > the line, other than arguing with it for 2 weeks before doing nothing? It ignores it---and enforces security---by using another line. Which is what Dan Bernstein should probably be doing to you. ---Dan
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (05/24/91)
In article <1991May17.142928.28492@sceard.Sceard.COM>, mrm@sceard.Sceard.COM (M.R.Murphy) writes: > I also wonder from time to time how much of the security software, > no, amend that to system software in general comes from people who, > even if they RTFM, don't UTFM and certainly don't understand the > philosophy behind TFM. You'd hope, if they did, that the solutions > would be a whole lot simpler. Or wouldn't be needed in the first > place. That's why the really good, elegant, clean systems (and I don't mean just UNIX) always spring from a very few minds. One, two, perhaps three, probably not more. The actual implementation may be the work of many, but the design must be the work of only a few, preferably only one. (It helps if the implementation is, too, but systems are getting a bit big for that nowadays.) Fred Brooks talks about this a bit (in The Mythical Man-Month, which I think everyone interested in any aspect of systems design should read). der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu