From secprog-return-485-jm=jmason.org@securityfocus.com Fri Sep 6 11:38:51 2002 Return-Path: Delivered-To: yyyy@localhost.spamassassin.taint.org Received: from localhost (jalapeno [127.0.0.1]) by jmason.org (Postfix) with ESMTP id 983E216F6D for ; 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 ; 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 ; 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: List-Post: List-Help: List-Unsubscribe: List-Subscribe: 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 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 Cc: "Webappsec Securityfocus.Com" , SECPROG Securityfocus Subject: Re: use of base image / delta image for automated recovery from attacks References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > ) 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