From: secprog-return-493-jm=jmason.org@securityfocus.com  Fri Sep  6 11:37:38 2002
Return-Path: <secprog-return-493-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 CEF2016F20
	for <jm@localhost>; Fri,  6 Sep 2002 11:36:19 +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:36:19 +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 g869vcC29825 for
    <jm@jmason.org>; Fri, 6 Sep 2002 10:57:38 +0100
Received: from outgoing.securityfocus.com (outgoing2.securityfocus.com
    [66.38.151.26]) by webnote.net (8.9.3/8.9.3) with ESMTP id VAA18304 for
    <jm@jmason.org>; Thu, 5 Sep 2002 21:36:52 +0100
Received: from lists.securityfocus.com (lists.securityfocus.com
    [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id
    E1EB28F2C6; Thu,  5 Sep 2002 13:38:50 -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 12968 invoked from network); 5 Sep 2002 17:15:58 -0000
Message-Id: <3D7793B5.8344A1B5@crystal.ncc.cc.nm.us>
Date: Thu, 05 Sep 2002 11:26:13 -0600
From: Scott MacKenzie <scottm@crystal.ncc.cc.nm.us>
Reply-To: scottm@crystal.ncc.cc.nm.us
Organization: =?iso-8859-1?Q?Din=E9?= College
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Mord <bmord@icon-nicholson.com>
Cc: Crispin Cowan <crispin@wirex.com>,
	"Webappsec Securityfocus.Com" <webappsec@securityfocus.com>,
	SECPROG Securityfocus <SECPROG@securityfocus.com>
Subject: Re: FW: use of base image / delta image for automated recovery
    from attacks
References: <NAEOJLMPJMJDFPLHIOJOOEGMDBAA.bmord@icon-nicholson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-12.6 required=7.0
	tests=KNOWN_MAILING_LIST,NOSPAM_INC,OUTLOOK_FW_MSG,
	      QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,
	      SPAM_PHRASE_05_08,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG
	version=2.50-cvs
X-Spam-Level: 

There is a software package that is used (or was up through w2k) 
on MicroSloth for this purpose. Ghost, or some such. One essentially 
"takes a picture" of the machine's proper config, and then upon 
schedule or demand replaces the machine's current config with the 
proper picture. It essentially over-writes the entire disk drive. 
Especially good for student access machines at libraries, etc.

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
> 
> >  I did my dissertation work in this area (Optimistic Computing) and so was
> >interested in applying it to the security problem. Unfortunately, you hit a
> >bunch of problems:
> 
> >    a.. 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.
> >    b.. 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 :)
> .    c.. 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. Obviously, you can't do this with partitions that
> accrue important state, e.g. a partition that stores database table data.
> But in your typical web application, most partitions do not accrue important
> state. For example, your typical web server or application server could have
> their entire state reset back to a known base state during each reboot
> without harm.
> The advantage of being less ambitious is that we have a quick and easy way
> to frustrate certain attacks without rewriting all of our software or
> spending lots of money on additional application-specific coding.
> 
> The first two problems you describe only occur if we become more ambitious
> and try to apply these same techniques to, for example, the database table
> partitions, where state changes remain important across reboots. That would
> certainly be a nice touch! But as you point out, many problems would have to
> be addressed first, and the hardest of these can not be abstracted away from
> the particular application. Not the least of these is the problem of writing
> heuristics for delineating good from malevolent state. That task is roughly
> analogous to what antiviral software authors do for a living, only this work
> could not be shared across many different systems as it would be specific to
> a paritcular application.
> 
> The third problem you mention - performance penalty - is an argument for
> doing this in hardware, much like hardware raid. Another argument for doing
> this in hardware is hack resistance. Changing the base instance should
> require physical access to the console, e.g. by requiring that you first
> flip a physical switch on your RAID hardware or modify a bios setting. If
> the base image can be modified remotely or by software, then you have to
> worry about whether an implementation flaw might permit a cracker to modify
> the base image remotely.
> 
> Ben

-- 
    (                                                ______
    ))   .-- Scott MacKenzie; Dine' College ISD --.   >===<--.
  C|~~| (>---  Phone/Voice Mail:  928-724-6639 ---<) | ; o |-'
   |  |  \---  Senior DBA/CARS Coordinator/Etc. --/  |  _  |
   `--'   `- Email: scottm@crystal.ncc.cc.nm.us -'   `-----'


