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

[Eugene Crosser <crosser@xxxxxxxxxxx>]

On Fri, 11 Jan 2002 00:40:53 +0100
Michael Stauber <cobalt@xxxxxxxxxxxxxx> wrote:

> >         Kernel:
> > ptrace          (Local, root access)
> 
> Just out of curiosity: Do you know a (working!) exploit for the present
> RaQ4 kernel in that regards?

I prefer the approach to fix the source of the possible trouble *before*
exploit is published.  If you say the ptrace problem is not exploitable
on Raq2, Qube2 and Raq4, I am only glad to hear that.  But I would much
prefer to be 100% sure.  That is, to have the version of the kernel where
the original problem is known to be fixed.

> > syncookie       (Remote, ? not sure how severe)
> 
> Well, that's a general problem with many Linux distributions. 

And I don't get it why, as it was fixed in the mainstream kernel sometime
around November 2001 (if memory serves).

> >         Glibc:
> > glob()          (Remote, potential DoS)
> 
> I guess most of the kernel and proftpd issues can be traced back to 
> underlying glibc issues.

Not the kernel ones.  Linux kernel is completely independent from glibc
(it has an own "lean and mean" version of libc in $kernel_src/lib).

> However, from a technical point of view a glibc replacement is a
> pretty tough cookie. To bad that "make world" is not an option here.

I don't think this is so much of a problem.  There was a .pkg a while ago
that replaced the whole glibc (if I get the accompanying comments right).
Very few, if any, binaries are statically linked *and* make use of glob()
*and* are remotely invokable.  So just replacing libc.so should suffice.

> >         Apps:
> > UW imapd        (Remote, root access? not sure)
> 
> I was wondering about that one as well the other week and asked here if 
> someone know if the imapd version the Cobalts use is vulnerable as well.

Here I would reiterate my comment on the ptrace issue: you will be
uncertain if your particular installation is vulnerable or not until
you have a version of the package that is *known* have the problem
cured.  (personally I just have installed imap-2001 in SSL mode and
filtered out access to standard imap and pop through tcpwrapper on
my own system).

I understand that my approach may be excessively paranoid, and some
of the mentioned problems may not be the issue due to one reason or
another.  What I would greatly appreciate is a matrix of known issues
and their relation to Cobalt products, maintained by Cobalt people.
If I could read that, for instance, the ptrace() problem does not affect
Raq4 because its kernel has nonexecutable stack patch applied (just an
example, I don't know if it has), I would feel much more confident in
the product I have paid for.  I would call it responsible approach on
the vendor's side.

Eugene