[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-users] recents hacks CERT # 25583



At 10:56 AM 2/24/2001, you wrote:
> Ok after a few hacks and a rehack I go in toutch with CERT, they are aware
of
> the vunerability, but were not aware that so many Cobalts owners had to
deal
> with this...

Are they aware that *thousands* of people using those same versions of BIND
and ProFTPd have had to deal with this?
I'm sure they are.

> I want the law to look at this,

Why?!? This is an issue with the above two programs, not with the Cobalt.
Don't you people get it yet?

< trim >

First while I agree 100% with Carrie's post that the security flaws lie not with Sun/Cobalt but the software and certainly the crackers who portscan and crack attempt darn near every box in my network every day, AND that it is *our* responsibility to ultimately keep them secured, I believe there is a grey area that Sun/Cobalt does have some responsibility to address.

Cobalt has created boxes that run a proprietary linux port and has marketed these boxes specifically as "easy to admin" internet servers. Further, upgrades & updates are supposed to be run from their official .pkg files and any variation outside their approved methods of administering these boxes voids your warranty.

The problem lies in what I have to perceive as some holes in Cobalt's timeliness and QA in creating/releasing these pkg files. As one previous poster commented, the lag time between a 'sploit being in widespread use and the fix for this being released by Cobalt is considerably longer than the norm. You don't see a hole in a Solaris port staying open very long... And how many times have people noted in this forum the installation of an update causing something weird or some undesired behavior on their Cobalt product? I know I personally had my CacheRaq die completely upon installing one of the fairly recent upgrades and it had to be sent back to Cobalt for a month to get fixed. (I'm just glad it was still under warranty and that a Squid cache by definition doesn't hold any critical data... Had this been a web server, well, it would've been a more than minor irritation to get all those sites up on another machine... )

It's a silly situation they've created. We're supposed to be responsible for security on our machines, but we're supposed to do it only with the tools given us by Cobalt, and those tools are often late in coming and/or have problems themselves.

There are some great people at Cobalt. I'm hoping they will get the ability to correct these problems.

Seeya,
Todd