SCO Responds to security bugs (was: SCO UNIX C2 Security)

Ronald S H Khoo ronald at robobar.co.uk
Sat Feb 23 13:01:26 AEST 1991


jpp at 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 at robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)



More information about the Comp.unix.sysv386 mailing list