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

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

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
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer