Hi Eugene, > If you say the ptrace problem is not exploitable on Raq2, Qube2 and Raq4, I > am only glad to hear that.
Personally I'm not sufficiently certain about that. What I know is that all exploit scripts which I found on obscure websites (and in the directory of a former webhosting customer) failed to work with 2.2.16C24 (RaQ3) and 2.2.16C28. Jeff Lovel (Sun Microsystems) seemed to be sufficiently certain about having ptrace() firmly under wrap back in October. Then there was this new ptrace() issue in the OpenWall kernel 2.2.19-ow3. Someone on the list mentioned it, Jeff replied that it was already fixed and then retracted that statement and wrote: > I apologize, I hadn't read my mail from Bugtraq as of yet. �I have > forwarded the details off the appropriate kernel maintainers here, and I > will update any information that comes available. > > Jeff I must have missed any followup on that if there was any at all. However, Kernel 2.2.16C32 (RaQ3) came out this week. From the release information and the link from there to SecurityFocus it is appears to fix just another ptrace() issue, even though the announcement on SecurityFocus is for the 2.4 series of kernels and not for the 2.2 series of kernels. I don't want to construct an arc here as I don't know if those events are related at all. > But I would much prefer to be 100% sure. Same here. I guess we have to continue to worry and to be wary. > 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). Yes and no. What if the kernel's libc implementation relies on the same buggy code as the glibc? Which apparently has been an issue in the past. > 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. 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 RaQ3-All-Security-3.0.1-8061.pkg which contains the glibc patch for the RaQ3 from November 2000 and took it apart. It contained ... glibc-2.1.3-21.i386.rpm glibc-devel-2.1.3-21.i386.rpm glibc-profile-2.1.3-21.i386.rpm ... so we're looking at a lot more than just a libc.so replacement. When you take the RPMs apart you'll notice how much stuff in /usr/bin gets replaced and how many other libraries are swapped out for good. So this is not just a heart replacement, but involves serious brain surgery as well. I'm sure someone more adept in programming C than I am can explain why this is such an issue. I have some general ideas about that, but don't know the stuff solidly enough to make a profound explanation which gets all the details right. I assume and suspect what really helped the Cobalt guys back then was the fact that the above RPMs were straight from RedHat (6.2 perhaps). However, nowadays I assume RedHat will devote less resources for throwing out a new glibc for RedHat 6.2 which would then be wrapped into a PKG and redistributed to us by the friendly folks in blue. ;o) > [..] (personally I just have installed imap-2001 in SSL mode [...] > 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. Way to go, Eugene. For a similar reason my DNS runs chrooted, which is a little excessive and paranoid as well, as bind-8.2.3 apprently looks to be fairly solid. > What I would greatly appreciate is a matrix of known issues > and their relation to Cobalt products, maintained by Cobalt people. Personally I'd prefer full disclosure and open discussion of all unsettled and unfixed issues. 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 wouldn't require a rocket scientist to then come up with an automated mass exploit which scans whole class A subnets and hits only the Cobalt's hard enough in just the right spots if all open issues were that well documented. Heck, it would even be possible to adapt the old bind-8.2.2 exploit-script for that purpose. When and if a company decides to go the path of full disclosure, then it also has to have a hardworking and dedicated staff on 24/7 standby to tackle any new issues which derive from that (I'm quite far from saying that SUN/Cobalt staff isn't hard working and/or dedicated, mind you). But such a firm commitment would also have an impact on the retail price of every shipped unit, I fear. However, I assume that it is not always clear even to the manufacturer and his senior staff what kind of issues certain aspects of the shipped product might have. -- With best regards, Michael Stauber [EMAIL PROTECTED] Unix/Linux Support Engineer _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
