Re: checking system integrity
On Fri, Feb 09, 2001 at 04:24:31PM +1100, Brian May wrote:
> Then again, looking at tripwire, I can't see what protects the
> tripwire executable from being tampered with either. I don't think it
> is possible unless you can mount it from some media that is guaranteed
> to be read-only (eg write protected floppy disk or read-only exported
> NFS).
You will find that this problem is inherent in any validation mechanism. The
only way to use a program like tripwire with any kind of assurance is to:
1. Boot the system from known good read-only media
2. Run the tripwire binary (or similar) from similar media
3. Store the database on write-once or write-protectable media
4. Boot the system back into its normal state
These steps must also be taken in order to verify the database with near-100%
assurance. However, it is still useful to run tripwire against the read-only
database periodically, because it could still catch a change. But the fact
that tripwire finds nothing cannot be trusted to mean that nothing has been
modified.
Another approach might be to use multi-attach storage devices, and have another
(network-isolated) host create, store and validate the database, without using
the shared media for any of its software.
> For example, what is to stop me, as the attacker, from replacing the
> tripwire binary, so that it appears to do all the checks OK, but fails
> to report any differences?
Nothing. As I said above, tripwire can be used for positive indication of a
change only (except under very artificial conditions, involving downtime), and
not for an indication that nothing has been changed.
--
- mdz
Reply to: