On Fri, 11 Jan 2002 00:40:53 +0100 Michael Stauber <[EMAIL PROTECTED]> 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 _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
