Re: [cobalt-security] any Security Team contact addresses at Cobalt or Sun?

[Eugene Crosser <crosser@xxxxxxxxxxx>]

Michael,

On Sat, 12 Jan 2002 17:00:56 +0100
Michael Stauber <cobalt@xxxxxxxxxxxxxx> wrote:

> > Very few, if any, binaries are statically linked *and* make use of glob()
> > *and* are remotely invokable.  
> 
> Yes, aside from the recent Qube3 glibc patch there was one for the RaQ3s and 
> RaQ4s back in Novemver 2000. I assume the key to successfully throw out a 
> patch like this requires a solid understanding of which services are 
> dynamically linked and which are not. Back then the libc patch fried 
> ChiliSoft ASP and you can imagine why. ;o)
> 
> > So just replacing libc.so should suffice.
> 
> Uuuuh ... not really. Just out of curiosity I downloaded 

Of course I somewhat oversimplified.
If you want to replace libc with a new version, you need to change this:

- shared objects of the libc (to make old and future dynamically
  linked executables use new libc)
- static objects of the libc (to make future statically linked binaries
  built on your system use new libc)
- include headers (to make future binaries compiled on your system see
  prototypes of new/changed functions)
- all binaries statically linked against libc (for nothing but
  consistency)

But if you are changing just a single function in libc, without the change
in its interface, you definitely don't need to replace the headers.
You need to replace only those of static binaries that use the changed
function, and the shared object that contains the fixed function.  That
will close the potential hole in existing programs on the system.  To
make any future binaries statically built on your system use the fixed
version of the function, you also want to replace the static library file.

So, this should be somewhat easier.
(I can go into further details if you want but in private mail
as this is getting offtopic).

> Personally I'd prefer full disclosure and open discussion of all unsettled 
> and unfixed issues.

Same here.

> BUT that is something which can backfire quite badly.
> 
> It would give people with bad intentions a list in hand with all the 
> vulnerabilities which the average Cobalt RaQ, Cube or XTR has. It

I think that those who need it already have it.  It's no rocket science
either.  I beleive that most of the time counter full-disclosure sentiment
is only excuse for maintainers who cannot react to the new threats in
timely manner...

Regards

Eugene