RE: *ICN - A Conspiracy of Inertia?

From: Benjamin Tomhave (falcon@cybersecret.com)
Date: 03/20/02 

From: "Benjamin Tomhave" <falcon@cybersecret.com>
To: <focus-ids@securityfocus.com>
Date: Tue, 19 Mar 2002 23:33:36 -0700

This is a fun thread! :)

Allow me to try to push more into theoretics and less into the "real world"
scenario (since I agree, for the most part, with all you folks about the
likelihood that this is pseudo-science and nothing more).

It seems to me that there are competing -- though not necessarily
contradictory -- concepts here: minimalist/strict systems vs. OO-based
systems. I mean OO in a very, very broad sense, particularly wrt open
platform, flexibility, code reusability, etc. It is substantially more
cost-effective to take an OO system (such as a UNIX or Linux variant) and
use it to support multiple applications than it is to create a brand-new,
super-strict system for each application. I believe that this is widely
agreed upon. However, it seems that there should be grounds for a
compromise. Perhaps it's taking the virtual server concept and refining it
so that you can have a flexible virtual platform for app/tool development,
but that can be easily and quickly configured in a super-strict/minimalist
manner. Almost like having a meta-language abstraction layer within the
virtual environment. Perhaps all of this already exists in the "perfect"
combination, though I've yet to find that silver bullet. Regardless, I'm
beginning to think that we've been approaching things too much from a
black/white perspective when instead we could be trying to better granulate
and develop shades of grey.

From an IDS perspective (to make this applicable to the list), the extension
would be this: if your apps ran in a self-contained virtual environment,
perhaps based off of some meta-language that could be tagged, almost like
network qos, then you could theoretically build a reliable detection scheme
that could easily id anomalies and take the appropriate action. Take a web
server, for example, written with php (this is a weak analogy, but it's what
came to mind). Even if you're dynamically generating the html via php,
perhaps including database calls, you still know how those calls are being
made and should be able to somehow restrict the site to only making those
calls. Why should anyone be able to take your php call and mangle it to
produce a buffer overflow or the sort. Now, this, of course, could be done
simply (or not) with error-checking in the code, but what if there was some
automated, fast way for the system to injest all the "legal" calls and then
simply block everything else? Also add a learning feature for calls that
are dynamically built. Of course, it would have to be modular in nature, in
order to support multiple virtual sites on one server, but anyway...

My point here, I guess, is that, like with anti-virus software, relying on
signatures for detection and response is a terrible pain in the rear and
will always be defeatable. However, for many reasons, this is the continued
approach that we take. Nonetheless, it's rarely a bad idea to try tipping
our brains on edge to try to redefine a problem and attack it from a
different angle. Who cares if the instigator is a quack? If it jars us out
of the status quo long enough to enable creative thinking, then cool!

Incidentally, this is in no way criticism of current products and R&D. I
have nothing but the utmost respect for organizations that are striving to
improve their products, whether it be NFR, ISS, Dragon, or a package built
around snort. I just wish that I could get my client networks cleaned up
enough and their sysadmin trained well enough to make adequate use of the
tools available...

-----Original Message-----
From: Marcus J. Ranum [mailto:mjr@nfr.com]
Sent: Tuesday, March 19, 2002 4:21 PM
To: robert_david_graham; falcon@cybersecret.com;
focus-ids@securityfocus.com
Subject: RE: *ICN - A Conspiracy of Inertia?

robert_david_graham wrote:
>You could solve more than 50% of UNIX exploits if you simply hooked
>exec("/bin/sh") in the kernel. Likewise, detecting changes to
>/etc/inetd.conf would solve another large percentage of UNIX exploits.

Come on Robert, you KNOW it's not that simple...

You'd need to hook /bin/sh /bin/ksh /bin/csh, and then...
You could temporarily fix more than 50% of UNIX exploits
for SEVERAL WEEKS. After that, the bad guys would learn that
they could use Perl instead of /bin/sh - or awk, or troff, or
any of a jillion commands that can do exactly the same thing
as the shell... That's without thinking about the C compiler...
And then you have to worry about combinations of things. What
if the Bad Guy calls the shell through a pipe process from
a troff command - suddenly any program that calls popen is
a potential parent process. The whole system fails very
quickly.

>RedHat could easily ship a version of Linux such that /bin/sh checks to see
>if <stdin>/<stdout> are socket handles, but if they did that, then exploit
>writers would simply choose another technique.

_Exactly_

It'll be interesting to see if we ever hear what Munson's
solution to security is. Lots of problems are easy to solve
right _now_ (simple fix for IIS holes: upgrade!) but they
aren't a solution that lasts for more than minor contact
with the enemy...

I also found the article insulting (and told the journalist so!)
in that it conveys the notion that the security product builders
are actually trying to suppress Munson's "solution" out of
economic fear. It shows a profound lack of understanding of the
economics of the high tech sector. If Munson's stuff was real
enough he wouldn't need to get it past the security practitioners
of the world - there's a big customer in Redmond who'd make him
rich even if every security expert in the world lined up against
him. Unless, of course, his stuff is B.S...

I was amazed that someone would actually print an accusation like
that without anything to back it up. :( It's like implying that
cops would try to drag their feet on preventing crimes for fear
of losing their jobs. As if!

Personally, if the security market evaporated tomorrow, I'd be
quite content to go back to system administration or something
fun and easy like writing games or browsers. :) It'd be nice to
be able to code without having to worry about security anymore,
huh?

mjr. 

---
Marcus J. Ranum          Chief Technology Officer, NFR Security, Inc.
Work:                    http://www.nfr.com
Personal:                http://www.ranum.com

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... the Unix and Windows worlds. ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Security that depends on user ignorance is so 1980s. ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Charles was unfamiliar with Fujitsu on Unix. ... libraries was 'more secure'. ... YOU introduced application security, not I. ...
    (comp.lang.cobol)
  • Re: RWW Security was compromised.
    ... Windows server security as my previous experience is Unix. ... > One of our clients RWW was compromised over the weekend. ...
    (microsoft.public.windows.server.sbs)
  • Re: What protects Unices from Virus like attacks ??
    ... >> what protects all Unix machines from such similar problems. ... > If a vulnerability is found for Unixen, ... I met security engineers that were aghast at some of the ... Many MS customers don't know what to do ...
    (comp.unix.questions)
  • Re: What protects Unices from Virus like attacks ??
    ... >> what protects all Unix machines from such similar problems. ... > If a vulnerability is found for Unixen, ... I met security engineers that were aghast at some of the ... Many MS customers don't know what to do ...
    (comp.unix.programmer)