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