[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-developers] Fwd: CERT Advisory CA-2002-17 ApacheWebServer Chunk HandlingVulnerability
- Subject: RE: [cobalt-developers] Fwd: CERT Advisory CA-2002-17 ApacheWebServer Chunk HandlingVulnerability
- From: "William L. Thomson Jr." <support@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed Jun 19 15:21:00 2002
- List-id: Discussion Forum for developers on Sun Cobalt Networks products <cobalt-developers.list.cobalt.com>
On Wed, 2002-06-19 at 14:18, Matthew Nuzum wrote:
>
> > True, but is that a reason to ignore the vunerability, and not upgrade
> > Apache?
>
> Need a good reason to not upgrade apache? I'll give you several...
> mod_casp (chilli asp), mod_php, mod_perl, mod_fp (front page),
> mod_auth_pam, mod_ssl, perl, openssl, and most importantly, QC (Quality
> Control).
Most of those are not as bad as you make them out to. Maybe PHP,
OpenSSL, and Front Page. But all others can be brought up to date by
simply recompiling the .so for the new version of Apache.
I do it all the time on my development server, and have only had
problems with PHP, and OpenSSL. Since I do not use PHP, that really was
not a big deal. OpenSSL is another story in itself.
That's were Apache 2.x comes in. I have heard from colleges that
compiling with SSL support is allot easier.
But asking Sun/Cobalt to upgrade to 2.x is pushing it.
> I've recently spent the time to recompile and install the above
> packages. To put it lightly, it's very hard. Getting the dependencies
> correct is no walk in the park.
Yes, I have been there. But if your post starts out with need reasons
why not to upgrade, why did you go through the effort? Kind of
contradictory no?
> How long would it take Sun Cobalt to get it working?
That is a question only the guys at Sun can answer?
> How long would you
> like them to test it before they release it to us?
Well it all depends on how the test. They could have created a program
to beat on what ever feature of the server they just upgraded. That
would be a matter of what the program was doing, and how fast the
machine beating on the Cobalt was. Could be a day, could be a month,
could be an hour or a minute?
Bottom line the Cobalt guys know what they are doing, so when they are
comfortable with it, that is usually good enough for me. Otherwise you
should not be buying a Cobalt, no?
> What happens when
> your customer's sites stop working because you upgraded Perl or PHP?
I would think that to be more of a design or implementation flaw. If
your or customers apps use features of what ever, and after the upgrade
they stop working, then they did not do a good job at developing their
app. If you have to upgrade each application every time the underlying
software is upgraded you need to rethink the design, no.
I have been working with Java for some time now, since 1.2, which I have
apps that are still running fine, that were originally created and
compiled under 1.2. Although for the sack of keeping up with the times,
I usually go back and update the apps, just to make sure I am not using
features that are or will be deprecated in future releases.
> If Sun released a hotfix, would you even apply it?
If it came from Sun then yes. If you can't trust the techs at Sun then
who can you trust? They are good enough to run things that we depend on
like Wall Street, and the Airline industry. So not our apps on Cobalt's?
As long as Sun stands behind it, and it's not say a pkg from
pkgmaster.com.
Nothing against those guys, they are great, but their pkg's are not
certified.
> I don't know if I
> would. I certainly wouldn't rush to do it. Every time Sun releases a
> new patch of any size/substance the list is flooded with messages about
> it and the problems it caused.
I have been one to complain in the past. In the end it was my fault not
the pkg from Sun/Cobalt. So I would argue on Sun's behalf 90% of the
time. Take if from me, putting your foot in your mouth tastes allot
worse than it sounds. :)
I have yet to come across a pkg released from Sun/Cobalt that I had
problems with, that were not created in one way or another by me or
something I did.
> Next, think about it from Sun/Cobalt's point of view. They would be
> supporting old systems that no longer provide revenue. Many of these
> systems never provided revenue to Sun (directly, only to Cobalt), and
> are therefore "Legacy" systems. How long does Dell provide
> patches/drivers/software updates for the PCs they sell? I'll bet the
> updates start to slow down after the first year and by the second it's
> forgotten.
This is completely off. Dell is selling mostly the hardware not the
software. Who goes to Dell for their custom software solutions?
People by Cobalt's for the software mostly. The fact that it has the
ability to ease system administration and expedite application
deployment. Which also makes you dependent on software upgrades and etc
from Sun/Cobalt. If Sun decide to discontinue after a period of time
that was not reasonable they would tarnish their reputation. Since most
of the people buying the equipment could not upgrade the software even
if they wanted to.
For this reason Sun still releases updates for the Raq2 and Raq3 just to
name a few, both of which have not been available to buy ever since I
first heard about and starting using a Cobalt. Almost two years ago.
I would say that Sun/Cobalt has done a great job of keeping their legacy
hardware up to date software wise.
I also assume that's why they have moved to the Sausalito architecture,
I may have the name wrong. Which allows the same pkgs to be installed on
a RaQ XTR, Qube 3 or, RaQ550.
> If you're talking about a root exploit, I'd have a different stance.
> We're not talking about that though. If someone wanted to DOS a server,
> they don't need buggy software to get the job done.
That point was made last post and I do agree, but still apache is
something that should be addressed at some point. Think of it from a
newbie point of view. They may just see some large details and not read
the fine print, and be discouraged because of it. Hell I had to read the
Cert alert and the article on Apache's web site to get the full scope
combined with knowledge of Apache and Unix. Which allot of Cobalt owners
may not have.
> A better direction for this discussion is, "How do I detect and prevent
> Dos and DDos attacks on my server?"
An excellent topic and a new thread should be started on this. As it is
something that applies to all. I would be interested to learn what other
do or have done to prevent Dos and DDos attacks. Or what we can come up
with as a group.
All good points, and good a debate. This should provide some feedback to
the Sun/Cobalt guys. Any comments from them?
Please do not take it personally, as we each are simply expressing
points of view for thought, and future improvement purposes.
Not a pissing contest. :)
--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax 707.766.8989
http://www.obsidian-studios.com