Checksums Done Right

[Matthew Garrett]

On Sat, Jun 30, 2007 at 09:14:17AM -0700, scott at cse.ucdavis.edu wrote:

> Ahh, you are correct. I was thinking of kernel-based rootkits being
> common. I have no evidence that states collision attacks are currently
> common. To clarify, it's trivially easy, using freely available source
> code[1] (31 secs/file now), to attack a system so that some valid
> executables have the same checksum as the vendors distributed copy but do
> something completely unexpected. If nothing else changes with those files
> (permissions, size, owner, group, time) it would easily fool many admins.

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. I'm not aware of anyone being able to 
demonstrate that with arbitrary executables yet.

> The way we run our dom0s is that they are not listening on the network,
> they have no users (other than admins), run little (mainly ssh-client)
> non-base install software, and they are physically secure. We have not yet
> seen a domU -> dom0 escalation attack (anyone else?). It may come
> eventually but thankfully it's not here yet. We could also build Xen from
> source, and examine the Xen diffs in great detail, but we aren't *that*
> paranoid, yet. Really the only known way to compromise a system and kernel
> in this environment is to control the mirror/media, control the Xen build
> environment or, control ring -1 (think "blue pill"[2] - heh installing Xen
> inside an already virtualized system would quickly degrade the quality of
> life).

So the real benefit is that you can do this on a live system, rather 
than having to reboot to known-good media? (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)

-- 
Matthew Garrett | mjg59 at srcf.ucam.org