Re: [cobalt-security] Re: Frontpage and ChiliSoft Vulns [WAS: Code Red Special Effects]

["Kevin D" <kdlists@xxxxxxxxxxxxxxx>]

From: "Michael J. Cannon" <mcannon@xxxxxxxxxxxxxx>

> They are theoretical, not yet real and focus on the fact the ISAPI filters
> that are FrontPage and ASP/DCOM+ and, soon, .NET and C# CLI, in IIS and,
> therefore, any OS that uses them are subject to the doctrine of 'inherent
> insecurity.'

What you're saying, I think, is that your web server is only as secure as
your weakest ISAPI filter. You could make the same argument about CGI, or
any other technology that allows for remote program execution on a web
server, couldn't you? The main issue here is that administrators should know
what they are running, and they should know the risks and how to mitigate
them.

> Of course, the argument can also be made that the insecurities, by the
same
> doctrine, are actually at the .asm level (in the machine architecture) or
as
> a result of such things as templates and the ability to cast 'badly
formed'
> pointer structures and map memory badly on the physical/machine or
> lower-level architectures.

If I understand you correctly, you're saying here that the root of the
problem is that the architecture allows things like buffer overflows? I
think that absolves the programmers just a bit too much. While, I do agree
that the architecture causes problems, these are problems of which
programmers should be well aware. These problems are preventable by good
programming practices.

> However, if that's the case, why haven't we seen
> the same level of exposure in Apache and other servers in Linux (other
than
> those 'extended' by ChiliSoft and others into the ASP and ISAPI
universes.)?

I can only surmise that the programs are better written. I think open source
allows security people to audit the code and find such bugs more quickly.

> Bottom line, FrontPage in particular and ISAPI and ASP in general are a
dumb
> idea, have been proven a dumb and insecure idea, and smart prople will do
> well to advise their clients and businesses to steer clear of them.

Perhaps this depends on perspective. In terms of security, ISAPI may be
risky. However, the dominance of ASP and up-and-coming PHP shows us that
these technologies are useful, and probably here to stay. Weren't the same
kinds of arguments made about mod perl and apache?

> Now a prediction:  with what's about to happen to the Microsoft
> implementations of RCL, RMI and, especially, RPC, we'll be saying the same
> thing about SOAP and .NET as we are currently saying about
FrontPage...only
> instead of  USD$2-billion a 12-day attack and media hysteria period, we''l
> be talking USD$20 and USD$40 billion in the same periods this time next
> year.

I'm a little foggy in the MS .net and SOAP area, but I do know that security
has become an increasing concern as the Internet has grown. New technologies
that allow computers to communicate more freely will always incur more
security risks. I have no desire to defend microsoft, but we can't simply
supress new technologies out of fear of the hacker boogie-man. What we
should do is point out the actual flaws in these new technologies and try to
fix them.

Code red cost some people a lot of money. However, most of those people were
ill prepared because they neglected to install a patch that had been in
existence for months. I don't think it's fair to blame the technology
architecture when you should be blaming the ineptitude of the
administrators.

Kevin