jpp@specialix.co.uk (John Pettitt) (02/22/91)
paulz@sco.COM (W. Paul Zola) writes: >I have good news for all those who have been having problems with >SCO's C2 Security. SCO Support has just released a Support Level >Supplement (SLS) which is designed to resolve many of these problems. >The supplement name is "The SCO UNIX System V/386 Release 3.2 Security >Supplement", and the SLS number is unx257. This SLS is availible >for anonymous UUCP via sosco, and through the usual support channels. >- What they don't tell you is that the SLS also fixes a rather interesting root security bug related to TCP/IP. In the light of the recent ISC uarea problems the way SCO responded deserves some publicity. We found a bug that allowed any user to log in as root by manipulating the network (probably a physical attack). We reported this to SCO with a note saying that we would like a fix ASAP (we have an Engineering Services agreement with SCO). Withing 2 weeks we had a beta of the SLS (unx257) that did indeed fix the problem. Before you ask - no I am not going to post the bug, however if you are running ODT or SCO Unix with TCP/IP and NFS you should get and install the upgrade ASAP. -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !
ronald@robobar.co.uk (Ronald S H Khoo) (02/23/91)
jpp@specialix.co.uk (John Pettitt) writes: > Before you ask - no I am not going to post the bug, Why not ? You're not one of those ARRRGH SECURITY THRU OBSCURITY people are you, John? I'm disappointed in you. Oh, sorry, you have a support contract, don't you? I suppose that binds you not to post about problems, does it ? And would you have posted otherwise ? The underlying problem is that InSecureWare's mods have made it possible for setuid() to fail, when the luid is unset. A more concrete example: in.rexecd (?) doesn't check (heh) for the return value of setuid(), and gives you a process anyway, so you get a root shell with the luid *still* unset, so you can just merrily su(C) to any user and get his luid set as well. Berzerkeley code, you see :-) Anyway, it just goes to show that ISC doesn't have the monopoly on keeping root-holes quiet. SCO have produced a fix, though, so I guess they win that particular race :-) Moral: when doing setuid(), *always* double check the success by doing getuid() afterwards to make sure you actually got there. Someone might have messed up the OS so that what USED TO BE true under Unix is no longer true under MangledNix. Sure the code wouldn't have failed under 4BSD, but that doesn't make it any less a bug :-) Has this been fixed in the current BSD rexecd? [link to bugs-4bsd] Another Moral: see what happens when you mess with Unix semantics ? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
jpp@specialix.co.uk (John Pettitt) (02/26/91)
ronald@robobar.co.uk (Ronald S H Khoo) writes: >jpp@specialix.co.uk (John Pettitt) writes: >> Before you ask - no I am not going to post the bug, >Why not ? You're not one of those ARRRGH SECURITY THRU OBSCURITY >people are you, John? I'm disappointed in you. Oh, sorry, you have a >support contract, don't you? I suppose that binds you not to post about >problems, does it ? And would you have posted otherwise ? No I don't believe in SECURITY THRU OBSCURITY. However if a vendor has produced a fix in good time and made it available free as SCO have done I see no reason to tell the world about the original problem. If you have a SCO box with TCP/IP & NFS and have not installed the security sls then it is quite easy to find the problem with a little experimentation. -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !
casey@gauss.llnl.gov (Casey Leedom) (02/26/91)
| From: ronald@robobar.co.uk (Ronald S H Khoo) | | | From: jpp@specialix.co.uk (John Pettitt) writes: | | | | Before you ask - no I am not going to post the bug, | | Why not? You're not one of those ARRRGH SECURITY THRU OBSCURITY people | are you, John? [[Ad homin attacks on John deleted.]] If SCO had learned about the bug and then not fixed it or told anyone about it, then they could be accused of security through obscurity. However, not broadcasting the exact method of making use of a security hole when distributing a bug patch for that hole is both common practice and good sense. Keith Bostic does this for 4BSD security patches for instance. You don't want people who haven't had time to install the security patches to get wiped out. There may well even be grounds for a negligence suit if a company did lay its customers open to assault this way. I think you owe John an apology. You should also probably cross your fingers and hope you don't get sued by some SCO customer for your post if it results in them suffering any losses. Casey
ronald@ibmpcug.co.uk (Ronald Khoo) (02/27/91)
[ Followups redirected away from bugs-4bsd again ] jpp@specialix.co.uk (John Pettitt) writes: > No I don't believe in SECURITY THRU OBSCURITY. I didn't think you did. You never used to, anyhow. > However if a vendor > has produced a fix in good time and made it available free as SCO have > done I see no reason to tell the world about the original problem. Well, this point would make sense if one were making the point to bash the vendor. For certain, in this case, that would not be my intention. First of all, I'd consider the bug to be BSD's for not checking the return value from setuid(). Secondly, as you say, SCO have made the a fix available for free, in fact, have not shied away from making it available for anon FTP *and* UUCP. which is very commendable. However, hiding the underlying information doesn't do the community at large any good. It's not all that often we get honest-to-goodness examples of how not checking the return value from a system call that "can't fail" results in a free root shell to anyone. Dramatic examples do sometimes help to persuade the skeptical. In a forum such as this which is *intended* to be technical, I feel that this outweighs any feeling that such disclosure would hurt the vendor. SCO's main competitor would seem to have lost this particular round anyway by appearing to conspire not to fix a bug till the news hit the net. SCO have been shown to have taken action unilaterally. I think this shows them in a good light, personally. I don't expect vendors to ship bugfree code. Oh, BTW, one of the non-publicly-available SLS's mentioned in the uunet.uu.net:/sco-archive/descriptions file (don't have the name of it handy cos I'm at home) seems to be a replacement rexecd. Is this meant to fix this bug without relaxing security ? It doesn't concern me personally -- I haven't got ODT or SCO Unix TCP -- I'm just curious. --
ronald@ibmpcug.co.uk (Ronald Khoo) (03/01/91)
casey@gauss.llnl.gov (Casey Leedom) writes: > [[Ad homin attacks on John deleted.]] Honestly! They weren't attacks of any kind. Maybe a gentle ribbing, and mostly just wanting to know exactly what John's position was. Besides, the point about the support contract was a serious question that I actually would have liked an answer to, though John didn't address it. That's his privilege. > If SCO had learned about the bug and then not fixed it or told anyone > about it, then they could be accused of security through obscurity. I wasn't referring to SCO with reference to that, just asking if John had changed his position, he says he hasn't and I accept that. > However, not broadcasting the exact method of making use of a security > hole when distributing a bug patch for that hole is both common practice > and good sense. This is arguable. The simple fix to the original SCO security bug, which can be applied even without getting any patches at all would be simply to disable rexecd in inetd.conf, as was implied in my original posting. In general, I would expect crackers to be far more knowledgeable than sysadmins, so spreading information as fast as possible would result in better, not worse security, since it means that sysadmins can secure their systems as soon as possible. A normal sysadmin might not have been able to figure out that rexecd was the problem, but a cracker might well have figured it out. Anyway, this bug has been pretty well known for ages. > You don't want people who haven't had time to install the > security patches to get wiped out. Similarly, you want to give sysadmins the opportunity to secure their system as soon as possible, before the crackers have had time to act. Remember: the bad guy normally gets his info fast, first, and before the average sysadmin. > I think you owe John an apology. If my original post came over like an insult, I apologise. It was certainly not meant that way at all. I didn't think John was a STO fan, and I thought that it was obvious that it was a humorous extraction of the michael from those who are. I certainly hope that most of us here would agree that the STO position is not defensible. John may well have his own reasons for not making the original bug clear, I had thought that this had anyway come up previously in the forum, perhaps I misremember. In any case it's clearly high time that the normal sysadmin got to know what the bug was. The cracker have known this hole for ages -- it's quite a well known one. Casey, no offence, but I really think you might consider lightening up a bit. --
jpp@specialix.co.uk (John Pettitt) (03/06/91)
ronald@ibmpcug.co.uk (Ronald Khoo) writes: >casey@gauss.llnl.gov (Casey Leedom) writes: >> [[Ad homin attacks on John deleted.]] >Honestly! They weren't attacks of any kind. Maybe a gentle ribbing, and >mostly just wanting to know exactly what John's position was. >Besides, the point about the support contract was a serious question >that I actually would have liked an answer to, though John didn't address it. >That's his privilege. Firstly our sco ES contract does not prohibit us from talking about problems in released software (it does on beta but tha't quite normal). Secondly the bug in question is not related to rexecd as ronald suggests. I am not going to be drawn into describing the bug however I will say again: If you are using SCO 3.2.[01] with TCP/IP and NFS you need to install the security fixes ! -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !