Re: [vox-tech] Verify Ubuntu files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] Verify Ubuntu files
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
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.
vox-tech mailing list