Re: Code Red is Not The Problem

[InfoSec News <isn () c4i org>]

Forwarded by: Renee Teunissen <renee () wittenburg10c nl>

Hi,

To realy understand these problems, people need to understand the
problems and difficulties in the software design process. One cant
state that firms "forget about" or "dont want" to patch security
leaks.

Another thing is that a lot of compagnies dont test their software as
they should, do propper testing with realistic test environment and
tooling. Many software projects are designed by people who's only
trade is to click an application together without undestanding what
realy is going on. Or understand the architecture. Or know what to
look for and know where flaws can be found.

On the otherhand, there are compiler extentions to protect you agains
bufferoverflows or at least if one occurs it will stop the program/
kill the process and does not execute the mallicious code. Thus
protect you agains the concequences of security-flaws in the software.

Please take a look at http://www.immunix.org/ they provide a linux
distribution with a compiler which can protect you. These techiques
can easily be applied to other compiler technologies as well. But do
compiler vendors think it is their problem? Are they will to take a
step in this?

But I agree with you we need to fight together (microsoft and *nix)
because - in my opinion - we both face the same problem and solving it
together is the only solution.

Just some thoughts.

Cheers,
Renee.


----- Original Message -----
From: "InfoSec News" <isn () c4i org>
To: <isn () attrition org>
Sent: Wednesday, August 08, 2001 10:38 AM
Subject: Re: [ISN] Code Red is Not The Problem


> Forwarded by: Darren Reed <darrenr () reed wattle id au>
>
> In some email I received from InfoSec News, sie wrote:
>
> [...]
>
> > But even with this latest major Internet security problem,
> > Corporate America and the government still don't get it, and
> > probably never will.
>
> [...]
>
> > The most significant danger and vulnerability facing the Wired
> > World is continuing to accept and standardize corporate and
> > consumer computer environments on technology that's proven time
> > and again to be insecure, unstable, and full of undocumented bugs
> > ("features") that routinely place the Internet community at risk.
> > But nobody wants to talk about that - not the government, not
> > CERT, not many security vendors, or most of the mainstream media.
> > Such analysis, although true, runs contrary to the status quo and
> > the industry-favoring 'party line' groupthink leading to increased
> > profits for everyone.
>
> [...]
>
> How about making providing software, with security bugs, for
> commercial use a felony or something that no disclaimer can waive
> responsibility for ? Maybe it should be a felony to release any
> software package with any known bugs or in doing so a software
> manufacturer voids any claim to hiding behind a disclaimer.
>
> What about going a step further and including deploying software with
> security bugs a felony, that way making system admins take more care
> in the software they install.
>
> I would not care if warranties that said "no buffer overflows" were
> only valid when used with specific hardware combinations (think ECC
> RAM, etc) specified by the software manufacturer.
>
> This should include BOTH Linux camps and Microsoft camps.
>
> It's becoming more and more clear that the industry itself is
> incapable of fixing these problems as it has no clear incentive.
> Time to change the incentive part of the equation and make it a
> disincentive to release any software with a security bug.  Without
> creating a system whereby the manufacturer of the software is
> responsible for their own work, I do not see any way to improve the
> quality of software as a whole.

[...]




-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.