brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/14/91)
CERT recently announced patched versions of telnetd and rlogind available from Sun for SunOS 4.1 and 4.1.1. The patches do stop the ``cover'' program which was posted here recently. I believe the ``uncover'' program posted recently also prevents ``cover'' from working. However, the bugs are not fixed. I was able to adapt my breaking program---still using the same holes that I posted some years back---to SunOS 4.1 and 4.1.1, both with and without the new telnetd/rlogind. Mitch Wright has agreed to be a reference for this. I believe the new version will also survive ``uncover''. What does this mean for you? In the short term: Hopefully the Netherland crackers will not be able to duplicate this work. In any case, to evade tty security this way under SunOS now takes such a complex sequence of manipulations that the average user won't even be tempted to try. (Legitimate applications also have to do a ridiculous amount of extra work, but never mind.) It is thus worthwhile to install the patched telnetd and rlogind. In the long term: SunOS is still insecure, and a sufficiently dedicated cracker can and will be able to get past tty security no matter how many other holes you close. It is inexcusable for Sun to leave this open. I'd like to give two further comments. One: Don't believe unjustified claims that a security hole has been fixed unless you can understand the fixes yourself. I've received a lot of e-mail asking whether SunOS 4.1 and 4.1.1 had the same problems, or saying that Sun and CERT gave the impression that the holes were closed, or insisting that the recently announced patches were more than enough to fix everything and that the tty problems would never reappear. Uh-huh. Sure they're fixed. I'm reminded of what so many sites told Stoll upon being told that they'd been broken into: ``We run a secure shop.'' Two: Security holes must be closed by logic, not just by testing. One of my louder critics in this discussion---a manager of a large network, unfortunately---thinks that by seeing break code he can invent a working fix. He's wrong. It's exactly that sort of thinking that produces one tty kludge after another, each of which is claimed to be the final solution and none of which really does the job. Sun's patched telnetd and rlogind do stop one program. That's good. But the CERT announcement implies that the patches are a ``SOLUTION'' to the entire vulnerability of the tty subsystem. That's absolutely wrong. The documentation inside Sun's patched source claims that the new versions will detect whenever a tty is open. That's absolutely wrong too. Just because one break program fails doesn't mean the system is secure. Unless you can logically prove your security, you have no security. I hope the SunOS 4.1.1 example gives people a healthy level of distrust for vendors' claims that a hole has been fixed. Sun---that's right, powerful vendor Sun---was told about a security-breaking program, did manage to stop that program, and then didn't look before it leaped into the claim that the problem was now completely solved. Why do people think this way? What is so difficult about logic and common sense that they have to be replaced by testing? You can't play around with security---and given how easy it is to *guarantee* that a mechanism is secure, there's no reason to play around. ---Dan
dave@jato.jpl.nasa.gov (Dave Hayes) (05/15/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >However, the bugs are not fixed. I was able to adapt my breaking >program---still using the same holes that I posted some years back---to >SunOS 4.1 and 4.1.1, both with and without the new telnetd/rlogind. >Mitch Wright has agreed to be a reference for this. I believe the new >version will also survive ``uncover''. Great. Thanks for your support. *sigh* I dunno why, but I am beginning to enjoy bashing you. However there does come a time to be a bit less frivolous. (WARNING: Slight meta-psychological digression here.) You asked: >Why do people think this way? What is so difficult about logic and >common sense that they have to be replaced by testing? You can't play >around with security---and given how easy it is to *guarantee* that a >mechanism is secure, there's no reason to play around. Yes, people ARE different aren't they? Have you ever considered that these people can't fix something they don't understand? Let's take this further...do you think that they'd ever WANT to understand when the information is presented in a negative way? Have you ever observed that when you tell a person outright that they are wrong...that they start to get even MORE wrong and MORE illogical and extremely nonsensical? Have you ever noticed that this phenomena also occurs when remarks about intelligence are made, or insinuations about stupidity are made? You know, I'll level with you. For all my negative remarks that I make about you (and still feel like making)...I realize (in my own folly) that because of this you won't listen to a word I say...it doesn't matter whether or not my remarks make sense. Now look at these two paragraphs: >Sun's patched telnetd and rlogind do stop one program. That's good. But >the CERT announcement implies that the patches are a ``SOLUTION'' to the >entire vulnerability of the tty subsystem. That's absolutely wrong. The >documentation inside Sun's patched source claims that the new versions >will detect whenever a tty is open. That's absolutely wrong too. >I hope the SunOS 4.1.1 example gives people a healthy level of distrust >for vendors' claims that a hole has been fixed. Sun---that's right, >powerful vendor Sun---was told about a security-breaking program, did >manage to stop that program, and then didn't look before it leaped into >the claim that the problem was now completely solved. Can you see how this applies to vendors? Sure, they resist making changes and I've had some pretty bad experiences with them. Why? Because we give them so much flak about these things. (I'm no exception) It's no wonder that they resist some guy who has nothing better to do than find out what they did wrong. Humans spend 80% of their lives pointing out others mistakes...if we spent half that time learning to correct them we'd probably be in a better place than we are now. SO when you ask "Why do people...", you might consider what effect you have had on them first. Perhaps in the case of the wayward vendors, you might offer them a comprehensive and SIMPLE solution to this problem, instead of just jumping up and down and pointing out the mistake. After all...coming up with break code doesn't really help you come up with a fix now, does it? -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh "It is a dragon, destroyer of all," cried the ants. Then a cat caught the lizard.
gwyn@smoke.brl.mil (Doug Gwyn) (05/15/91)
In article <25239:May1416:21:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In the long term: SunOS is still insecure, and a sufficiently dedicated >cracker can and will be able to get past tty security no matter how many >other holes you close. It is inexcusable for Sun to leave this open. Why? Has Sun made any promises about absolute security of SunOS? For example, are they claiming B2 certification for it? I've always had the impression that UNIX was intended for resource sharing much more than for resource hiding, and that the security mechanisms were meant to prevent accidental problems, not dedicated attacks. I guarantee that there are other security problems on most versions of UNIX besides the one you've been carrying on about. What makes that one problem so much more significant than the others?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/15/91)
In article <16155@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <25239:May1416:21:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In the long term: SunOS is still insecure, and a sufficiently dedicated > >cracker can and will be able to get past tty security no matter how many > >other holes you close. It is inexcusable for Sun to leave this open. > Why? Has Sun made any promises about absolute security of SunOS? > For example, are they claiming B2 certification for it? Well, they do have an option which, they claim, provides C2 security. But I was thinking more on ethical grounds. > I've always had the impression that UNIX was intended for resource > sharing much more than for resource hiding, and that the security > mechanisms were meant to prevent accidental problems, not dedicated > attacks. Perhaps you didn't notice the complaint just a few weeks back about how somebody was getting output from someone else's background process under SunOS 4.0. That sounds like a problem to me. And the commercial world (not to mention universities) has to pay attention to dedicated attacks. > I guarantee that there are other security problems on most versions > of UNIX besides the one you've been carrying on about. What makes > that one problem so much more significant than the others? The bugs I've pointed out are on practically every BSD-derived UNIX system, meaning practically every UNIX machine on the Internet. The smaller set of bugs pointed out by Bellovin are on AT&T-derived UNIX systems too. Very few such dangerous holes have survived so long on so many machines. ---Dan
jfh@rpp386.cactus.org (John F Haugh II) (05/16/91)
In article <7491:May1502:05:3291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <16155@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >> In article <25239:May1416:21:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> >In the long term: SunOS is still insecure, and a sufficiently dedicated >> >cracker can and will be able to get past tty security no matter how many >> >other holes you close. It is inexcusable for Sun to leave this open. >> Why? Has Sun made any promises about absolute security of SunOS? >> For example, are they claiming B2 certification for it? > >Well, they do have an option which, they claim, provides C2 security. >But I was thinking more on ethical grounds. I understand that Sun does have a Federal Systems Division, or whatever they call their spook work, and supposedly are in evaluation, or done or whatnot on a trusted system. I've always assumed that when Dan complains about security holes in alt.security that at the very least he is referring to a system that pretends to be secure. Complaining about security on a system that makes no claims is like complaining that MS-DOS lets anyone reformat the C: drive - it makes you feel real good, but then no one said you couldn't just reformat the disk in the first place. >> I've always had the impression that UNIX was intended for resource >> sharing much more than for resource hiding, and that the security >> mechanisms were meant to prevent accidental problems, not dedicated >> attacks. > >Perhaps you didn't notice the complaint just a few weeks back about how >somebody was getting output from someone else's background process under >SunOS 4.0. That sounds like a problem to me. And the commercial world >(not to mention universities) has to pay attention to dedicated attacks. I have to agree with Dan on this one. UNIX is less and less an OS for "resource sharing" and one for getting "real work" done. This may not be pleasing to the old-time UNIX users (I can't stand SVR* for example), but selling UNIX to the commercial masses does pay the rent. There is something particularly refreshing about seeing AIX run on a 3090/600-J with all that vector stuff and 100GB of spinning storage - it just makes my skin crawl. >> I guarantee that there are other security problems on most versions >> of UNIX besides the one you've been carrying on about. What makes >> that one problem so much more significant than the others? > >The bugs I've pointed out are on practically every BSD-derived UNIX >system, meaning practically every UNIX machine on the Internet. The >smaller set of bugs pointed out by Bellovin are on AT&T-derived UNIX >systems too. Very few such dangerous holes have survived so long on so >many machines. Nonsense. There are still vendors that insist on shipping machines with setuid shell scripts. I'll admit your problem is serious, but not the one true serious security hole in the system. NFS is by far the biggest hole on the planet - I regularly use it to become root on test systems that I've forgotten the root password to. And the worst part is that it lets you creep about so nicely in a warm, friendly, trusting environment. Kinda like the stomach flu, only worse. -- 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."
gwyn@smoke.brl.mil (Doug Gwyn) (05/17/91)
In article <19283@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >NFS is by far the biggest hole on the planet ... Quite possibly true. This week Moss & I discovered yet another in a long, continuing series of NFS deficiencies. We had an application that locked a file, did some I/O to it, and truncated it to final length. (Basically, deleting records from a database.) In one case the final length was 0 bytes, which was correctly shown by a subsequent "ls" command, but amazingly if one "cat"ted the file quite a bit of data was "read", different data each time. Our theory is that the local NFS buffer cache was not being coordinated with the remote inode that was affected by the ftruncate() system call. (Yes, we had lock and stat daemons running on both local and remote hosts.) The data that could be "read" from the supposedly 0-length file had to be coming from somewhere in the kernel, presumably from a block buffer cache. This would be an interesting way to snoop on the contents of files that one was not supposed to be able to access.. P.S. SunOS 4.0.3 (local) and Irix 3.3.1 (remote), if somebody wants to try to track this down.
jim@segue.segue.com (Jim Balter) (05/17/91)
In article <1991May14.184506.4756@jato.jpl.nasa.gov> dave@jato.jpl.nasa.gov writes: >SO when you ask "Why do people...", you might consider what effect you >have had on them first. Perhaps in the case of the wayward vendors, >you might offer them a comprehensive and SIMPLE solution to this problem, >instead of just jumping up and down and pointing out the mistake. Dan appears to have offered what he believes to be a comprehensive solution, and as simple as he thinks he can make it. ("Make things as simple as possible, but no simpler." -- Al E.) The one jumping up and down is you. >After all...coming up with break code doesn't really help you come up >with a fix now, does it? Nor does posting it all over the net, now, does it? Dan provides a solution but doesn't provide the break code. Ed Carp and you and a bunch of others yell and scream in a most insulting, rude, impolite and uninformed manner at Dan. Now you say that he should offer a solution but not come up with break code. Go figger. As I see it, a bunch of non-wizardly sys admins are trying to disrupt a technical discussion about tty security problems and how to fix them, with demands that some code that demonstrates the problem be posted so that they can "understand the problem" and then go hack and slash or whatever in order to "fix" the problem. This is simply not a competent approach toward problem solving. If you aren't competent (meaning possessing required knowledge and skills; nothing pejorative) to understand the problem from the discussion so far, what can possibly make you think that you are competent to solve the problem based upon the program that breaks the system? But many people don't seem to understand this. There are a lot of programmers who, given an equation solver, some equations, and the right answer, would run off and hack on the equation solver until it yielded the right answer, without ever cracking a book on mathematics. (And some are going, Yeah, what's wrong with that?") It might be better if programmers were given intense analytical training before being let near a computer, with its instantly gratifying feedback.
dave@jato.jpl.nasa.gov (Dave Hayes) (05/18/91)
jim@segue.segue.com (Jim Balter) writes: >Dan appears to have offered what he believes to be a comprehensive solution, >and as simple as he thinks he can make it. ("Make things as simple as >possible, but no simpler." -- Al E.) That maybe how it appears to you. I certainly don't know how it appeared to the vendors. I can only suspect that it appeared too complex and convoluted to vendors who would not listen....either that or the information is presented in a hostile way. Nevertheless Dan did ask a question. ("Why do people think this way") I merely answered. That's more than he's done for me. > The one jumping up and down is you. Damn straight. I have no problems jumping up and down about what is going on with disemmination of security infomration..and not just Dan's personal problem with being helpful (as opposed to determining what help everybody needs). I get paid to jump up and down about this stuff. I don't mind it one bit. >>After all...coming up with break code doesn't really help you come up >>with a fix now, does it? >Nor does posting it all over the net, now, does it? I'd be willing to wager a large amount of money that posting code over the net would produce a fix MUCH FASTER then coming up with the code. >Dan provides a solution but doesn't provide the break code. Ed Carp and >you and a bunch of others yell and scream in a most insulting, rude, impolite >and uninformed manner at Dan. Now think for a second. Why do you think that we feel the way we do? Note the common thread in the people who scream a lot (and I have a *BIG* mouth when I want to have one)...we all have a legitimate interest in any security problems over the internet. Dan, in all his holy infinite wisdom, has created an effect on us by posting enough information to produce more crackers but not enough to allow us to deal with them. Fortunately there are other members of the community here that have more consideration and less ego who are willing to help, but IMHO there's no excuse for Dan's behavior...and he shoudl EXPECT the rudeness (in fact I believe he revels in it). > Now you say that he should offer a solution but not come up with break code. > Go figger. You should. I was commenting upon his effort to break SunOS 4.1/4.1.1; trying to figure what that would get him. It was also a very sarcastic comment. >As I see it, a bunch of non-wizardly sys admins are trying to disrupt a >technical discussion about tty security problems and how to fix them, Boy this sounds elitist. I guess us humans do need to demonstrate their superiority over others time and time again...it's a fact of human nature. >with demands that some code that demonstrates the problem be posted so that >they can "understand the problem" and then go hack and slash or whatever >in order to "fix" the problem. This is simply not a competent approach >toward problem solving. It is also incompetant to post details of the problem if you aren't willing to post fixes/solutions and a description of the problem. I personally believe that security by obscurity isn't (what a time worn phrase), but if you believe different...then WHY POST ANYTHING AT ALL. Anything else is blatant and obnoxious hypocracy. If you aren't competent (meaning possessing required >knowledge and skills; nothing pejorative) to understand the problem from >the discussion so far, what can possibly make you think that you are competent >to solve the problem based upon the program that breaks the system? This is an assumption about the way people think. I guarantee you that there exists someone out there who couldn't understand the conceptual details until you showed them some code. Interestingly enough, there is a musician who I am teaching who doesn't understand a whit about altered dominant scales on paper, but when I played them for him he immediately understood. Please cut the rest of humanity some slack. There are a LOT of different types of people out here. -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh Think enough and you won't know anything!
jim@segue.segue.com (Jim Balter) (05/20/91)
In article <1991May17.181554.26175@jato.jpl.nasa.gov> dave@jato.jpl.nasa.gov writes: >jim@segue.segue.com (Jim Balter) writes: >>Dan appears to have offered ... > >That maybe how it appears to you. ... I was speaking of how things appear to Dan, not to me, you, or vendors. Please follow the thread. >> The one jumping up and down is you. > >Damn straight. But you accused Dan of jumping up and down. Please follow the thread. >>>After all...coming up with break code doesn't really help you come up >>>with a fix now, does it? >>Nor does posting it all over the net, now, does it? > >I'd be willing to wager a large amount of money that posting code over the net >would produce a fix MUCH FASTER then coming up with the code. Rational communication with you appears to be beyond my abilities. I will desist. I apologize for wasting the time of other readers. >>Dan provides a solution but doesn't provide the break code. Ed Carp and >>you and a bunch of others yell and scream in a most insulting, rude, impolite >>and uninformed manner at Dan. > >Now think for a second. Why do you think that we feel the way we do? Only your therapists know for sure. >...and he shoudl EXPECT the rudeness (in fact >I believe he revels in it). Slaveowners believe that their slaves wanted to be mastered, too. Rationalization is an amazing achievement of the human brain.