> 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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
