-----Original Message----- From: Crispin Cowan [mailto:crispinat_private] 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
This archive was generated by hypermail 2b30 : Thu Sep 05 2002 - 09:36:55 PDT