[vox-tech] Verify Ubuntu files

[Bill Broadley]

Bill Kendrick wrote:
> On Wed, Aug 13, 2008 at 02:03:40AM -0700, Rick Moen wrote:
>>> Booting known good media is much better, although even then it's
>>> pretty trivial to subvert.
>> Oh, do tell.
> 
> Just a guess, but maybe this is in relation to his later comment about
> tricking users into installing their OS as a guest OS on top of a
> secret, compromised OS...

Ah, well tripwire will monitor as much of the filesystem as you tell it to. 
The problem is that filesystems are huge, and the churn rate is pretty high. 
Seems like most weeks centos or ubuntu have 10-20 packages out per week, 
probably 10 times that number of files touched.  In general new files are 
harder to catch than changed files.  Things like /usr/bin/sshd2 appearing is 
much harder to catch than /usr/sbin/sshd changing, and even that isn't 
uncommon with a patch. For instance my /usr/sbin/sshd changed in mid May on 
ubuntu 8.04.  That file depends on /lib/libpam.so.0.81.6 changes in May, 
libdbus changes in may, and libcrypto changed in june.  So sure in single user
mode booting from CD I could have reviewed each of these changed, googled 
around... crap no network, using a second computer seen which files were in 
which packages, checked their checksums, checked the local checksum, and then 
allowed tripwire to sign the new database.

So sure, you could check the bootsector, tripwire that, then of course 
everything you boot with under /boot, especially the initrd (which changes 
often), and of course every file under /etc/init.d.  Of course those scripts
all have paths, sometimes absolute, sometimes relative, sometimes relying on 
the default environment... so they depend on 1000's of files... some of which 
are binaries.... some of which are libraries... and of course those files make
system calls to the (hopefully trust worthy kernel).

So the basic downfall is that the churn rate is high, tripwire assumes the 
system is secure, and is basically zero help with making sure the updates are 
secure.  So to keep a single system secure would likely be close to a fulltime
job, and over the course of 3 years you would have have to track down, verify 
and update the database 100's of times for 1000's of packages, and 10,000's of 
files.

Or you could use CDR.

Now if you instead rely on a mirror you know all possible checksums (for 
patches, kernels, modules, and all binaries) and there are no race conditions 
(the mirror knows the old and new checksums of all files/packages BEFORE you 
get the patch).  When combined with virtualization then you get the benefits 
of a secure environment to check the filesystem as well.

Granted a hacked would hide pretty well, find a out of the way place in the 
swap partition, even in the empty space of existing blocks then write a single
binary, or even a python script that slurps that up, decrypts it, and builds
itself a little toolkit of trojans, backdoors, etc.  Or even just sabotaging 
an update so the system THINGS it's running the secure version of something, 
but is in fact running and authentic offical binary of some previous version 
with a known security vulnerability.

So basically unless your are hyper vigilant and often verify your machine only 
run trusted kernel/boot media, and audit every of innumerable updates to your 
system, once you are hacked it's too late.  Long gone are the times when 
md5sum /bin/login told you something useful.