Checksums Done Right

[scott at cse.ucdavis.edu]

> Right, but being able to create a collision isn't the same as being able
> to create a *useful* collision. You need to be able to alter the
> functionality of the program in a very specific way in order to use it
> to escalate privileges.

Escalation of privileges is one attack, yes. Although the type of "attack"
I'm talking about is for users that already have the ability to write a
root-owned binary. I'm describing more of a DoS attack that basically just
keeps admins scratching their heads. It doesn't have to be a useful
collision to cause headaches. The main point is that md5 is broken and
should be retired[1] (note: that's the "R" in RSA writing that "md5 is
broken" not just me).

> So the real benefit is that you can do this on a live system, rather
> than having to reboot to known-good media?

Potentially, yes. Of course I envision malicious kernel modules being
created that remove themselves from the filesystem while running then at
the last minute before shutting down write what's necessary to load
themselves on boot again. In that case you'd have to shutdown the system
to be certain.

The additional benefit is that we can link the file validation to the
maintainers version. Tripwire doesn't do this but debsums does (kinda - it
uses a cache instead of the known good from a central source like a
mirror). We see a need for a centralized tripwire-like system that only
trusts the maintainers/distributions and distrusts both the running kernel
and any local database of installed packages/files. Oh ya, we want it to
be cross-distribution too.

> (I'm sceptical about the idea
> of attackers being able to virtualise a system without anybody noticing.
> Latency of privileged instructions would change in a pretty obvious way)

Then I invite you to join the ongoing "blue pill" debate. That is really
outside the scope of CDR but still an interesting attack vector
none-the-less. We assume you get the "high ground" first.

Scott
---------
[1]  http://mail.python.org/pipermail/python-dev/2005-December/058850.html