[vox-tech] Verify Ubuntu files

[Bill Broadley]

Rick Moen wrote:
> Doing any IDS check from known-good boot media is obviously far better
> (where one can afford the downtime), and the only way any integrity
> check of the boot chain can possibly hope to be reliable.

Well you can't lie to the dom0, so using the dom0 kernel is much like using 
secure media... except you don't need the downtime, and the domU can't tell 
when it's happening.

>> Booting known good media is much better, although even then it's
>> pretty trivial to subvert.
> 
> Oh, do tell.

Well a single successful tweak can compromise a system in such a way that 
nothing else on the filesystem changes.  So for instance if /sbin/shutdown
hides the tracks, then when you reboot to safe media you never see it... it's 
harder to hide from the dom0.  So once you are in you can stick with 
compromising only things in memory till the admin reruns tripwire.

>> Of course it's relatively trivial to hack a machine, not change a single 
>> binary, and open up a back door.
> 
> I assume you mean that _if_ you have cracked a machine, it's easy to
> avoid changing the binaries, and yet open a back door.  However, you
> must make a critical change to system configuration to make that
> persist, which change then is part of the forensic trail.

True, but tripwire seems best at detecting changed binaries, there are many 
places on a filesystem where you can add a text file that creates a security 
hole.  Sure it's possible to detect the change, but it's pretty easy to
just make a hook for the next time you run the tripwire client, or apt-get update.


> That would be a rather careless sysadmin who doesn't detect the fact
> that the TW policy file has been altered.  All of the thing's files, you
> may recall, are crypto-signed, right down to the reports -- and that
> would be pretty pointless if you didn't always (at minimum) use its
> siggen utility from read-only media to check them.  Even at that, it's 
> theoretically possible that a subverted runtime system (not rebooted to
> known-good media) could jigger the siggen checks to make it lie and
> report the expected hash values, but I'll believe that when I see it.

Hiding things better on shutdown is common, and instrumenting tripwire
so that changes aren't written to critical files until the sysadmin is 
updating the database is common.  With common security policies requiring 
security patches be applied within days to a week (so it's often) it's rather 
rare to do the most secure shutdown, mount RO media, check the database, 
patch, mount the media RW, update the database, reboot.

> (FWIW, I don't like Tripwire:  Too slow, far too much hassle to admin,
> too crufty; but I'm glad to give credit for what they did thoughtfully.)

The common method, a signed local database is no more secure than the local 
RPM database, it's inherently broken, it assumes you are secure to begin with,
assumes that you can trust the kernel, and assumes that there never is an 
insecure update.  It's rather common for instance for a hack to cause a file 
read to report one checksum (say one of the tripwire binaries) yet when you 
run it you get a different binary.