124 lines
5.7 KiB
Plaintext
124 lines
5.7 KiB
Plaintext
From secprog-return-485-jm=jmason.org@securityfocus.com Fri Sep 6 11:38:51 2002
|
|
Return-Path: <secprog-return-485-yyyy=example.com@securityfocus.com>
|
|
Delivered-To: yyyy@localhost.example.com
|
|
Received: from localhost (jalapeno [127.0.0.1])
|
|
by jmason.org (Postfix) with ESMTP id 983E216F6D
|
|
for <jm@localhost>; Fri, 6 Sep 2002 11:37:33 +0100 (IST)
|
|
Received: from jalapeno [127.0.0.1]
|
|
by localhost with IMAP (fetchmail-5.9.0)
|
|
for jm@localhost (single-drop); Fri, 06 Sep 2002 11:37:33 +0100 (IST)
|
|
Received: from webnote.net (mail.webnote.net [193.120.211.219]) by
|
|
dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g869wcC29994 for
|
|
<jm@jmason.org>; Fri, 6 Sep 2002 10:58:38 +0100
|
|
Received: from outgoing.securityfocus.com (outgoing3.securityfocus.com
|
|
[66.38.151.27]) by webnote.net (8.9.3/8.9.3) with ESMTP id UAA17986 for
|
|
<jm@jmason.org>; Thu, 5 Sep 2002 20:39:45 +0100
|
|
Received: from lists.securityfocus.com (lists.securityfocus.com
|
|
[66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id
|
|
26D1DA3106; Thu, 5 Sep 2002 10:42:53 -0600 (MDT)
|
|
Mailing-List: contact secprog-help@securityfocus.com; run by ezmlm
|
|
Precedence: bulk
|
|
List-Id: <secprog.list-id.securityfocus.com>
|
|
List-Post: <mailto:secprog@securityfocus.com>
|
|
List-Help: <mailto:secprog-help@securityfocus.com>
|
|
List-Unsubscribe: <mailto:secprog-unsubscribe@securityfocus.com>
|
|
List-Subscribe: <mailto:secprog-subscribe@securityfocus.com>
|
|
Delivered-To: mailing list secprog@securityfocus.com
|
|
Delivered-To: moderator for secprog@securityfocus.com
|
|
Received: (qmail 4920 invoked from network); 4 Sep 2002 23:14:36 -0000
|
|
Message-Id: <3D76977B.9010606@wirex.com>
|
|
Date: Wed, 04 Sep 2002 16:30:03 -0700
|
|
From: Crispin Cowan <crispin@wirex.com>
|
|
Organization: WireX Communications, Inc.
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
|
|
X-Accept-Language: en-us, en
|
|
MIME-Version: 1.0
|
|
To: Ben Mord <bmord@icon-nicholson.com>
|
|
Cc: "Webappsec Securityfocus.Com" <webappsec@securityfocus.com>,
|
|
SECPROG Securityfocus <SECPROG@securityfocus.com>
|
|
Subject: Re: use of base image / delta image for automated recovery from
|
|
attacks
|
|
References: <NAEOJLMPJMJDFPLHIOJOMEGLDBAA.bmord@icon-nicholson.com>
|
|
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
|
|
Content-Transfer-Encoding: 7bit
|
|
X-Spam-Status: No, hits=-12.9 required=7.0
|
|
tests=AWL,EMAIL_ATTRIBUTION,KNOWN_MAILING_LIST,NOSPAM_INC,
|
|
QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,
|
|
SPAM_PHRASE_08_13,USER_AGENT,USER_AGENT_MOZILLA_UA,
|
|
X_ACCEPT_LANG
|
|
version=2.50-cvs
|
|
X-Spam-Level:
|
|
|
|
Ben Mord wrote:
|
|
|
|
> -----Original Message-----
|
|
> *From:* Crispin Cowan [mailto:crispin@wirex.com]
|
|
> *Sent:* Wednesday, September 04, 2002 5:46 PM
|
|
> *To:* Ben Mord
|
|
> *Cc:* Webappsec Securityfocus.Com; SECPROG Securityfocus
|
|
> *Subject:* Re: use of base image / delta image for automated
|
|
> recovery from attacks
|
|
>
|
|
> Ben Mord wrote:
|
|
>
|
|
>>I was inspired by a mode of operation supported by VMWare. [use VMWare's ability to rolll back state to recover from intrusions]
|
|
>>
|
|
> I did my dissertation work in this area (Optimistic Computing
|
|
> <http://www.cse.ogi.edu/%7Ecrispin/hope.pubs.html>) and so was
|
|
> interested in applying it to the security problem. Unfortunately,
|
|
> you hit a bunch of problems:
|
|
>
|
|
> * When can you "commit" a state as being "good"? You can't
|
|
> run from a redo log forever; the performance and storage
|
|
> penalties accumulate. Even log structured file systems
|
|
> garbage collect eventually. So you have to commit sometime.
|
|
> The problem is that if you commit too eagerly, you might
|
|
> commit corrupted state. If you commit too conservatively,
|
|
> you eat performance and storage penalties.
|
|
> * What do you do if you discover that there is corrupted state
|
|
> in the *middle* of your redo log, and you want some of the
|
|
> critical state that comes after it? You need some way to dig
|
|
> the corruption out of the middle and save the rest. My
|
|
> dissertation solves this problem, but you have to re-write
|
|
> everything in my programming language :)
|
|
> * Just doing this at all imposes substantial performance
|
|
> penalties. I love VMWare, and use it every day (the best
|
|
> $200 I ever spent on software) but it is not very fast.
|
|
>
|
|
> My proposed solution to the first two problems you mention is to be
|
|
> less ambitious. The idea is that you *never* commit - instead, you
|
|
> simply revert to base state on reboot.
|
|
|
|
Ah. In that case, you can use something considerably less powerful than
|
|
VMWare. All you need is a machine configured to boot from CD-ROM and use
|
|
a RAM disk for scratch space. Numerous Linux distros are available that
|
|
let you boot a stateless but functional system from CD-ROM.
|
|
|
|
> Obviously, you can't do this with partitions that accrue important
|
|
> state, e.g. a partition that stores database table data.
|
|
|
|
... but if you *do* want some state to persist, then you need a
|
|
mountable writable partition. To protect it, you need some kind of
|
|
access control management to decide who can do what to the writable
|
|
partition, blah blah blah ... and before you know it, the security
|
|
problem starts to look just like it does for conventional servers.
|
|
|
|
Simple approxmation to this: make /usr a separate partion, and mount it
|
|
read-only:
|
|
|
|
* The good news: attackers that want to trojan your software have to
|
|
reboot, at least.
|
|
* The bad news: administrators that want to update your software
|
|
have to reboot, at least.
|
|
|
|
Crispin
|
|
|
|
--
|
|
Crispin Cowan, Ph.D.
|
|
Chief Scientist, WireX http://wirex.com/~crispin/
|
|
Security Hardened Linux Distribution: http://immunix.org
|
|
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
|
|
|
|
|
|
|