Xref: utzoo comp.unix.sysv386:5539 comp.bugs.4bsd:1762
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!slxsys!ibmpcug!ronald
From: ronald@ibmpcug.co.uk (Ronald Khoo)
Newsgroups: comp.unix.sysv386,comp.bugs.4bsd
Subject: Re: SCO Responds to security bugs (was: SCO UNIX C2 Security)
Keywords: error checking
Message-ID: <1991Feb27.000357.17213@ibmpcug.co.uk>
Date: 27 Feb 91 00:03:57 GMT
References: <43@talgras.UUCP> <14791@scorn.sco.COM> <1991Feb22.093441.8639@specialix.co.uk> <1991Feb23.020126.8064@robobar.co.uk> <1991Feb26.092431.23866@specialix.co.uk>
Reply-To: ronald@robobar.Co.Uk (Ronald Khoo)
Followup-To: comp.unix.sysv386
Organization: At home, should be in bed, really.
Lines: 40

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

--