Slashdot Mirror
Known-Good MD5 Database
bgp4 writes "Have you ever examined a system you thought was broken into but you weren't sure? If only you had run an integrity verification program like osiris or Tripwire first you could have figured out what programs had been changed. In an effort to help out in the instances when you can't answer the question "what was this like before?" we've constructed a searchable database of MD5 and SHA-1 hashes for files in many standard operating systems. You can search using the filename or the checksum and see if you have a trojaned binary or an overactive imagination. Currently at knowngoods.org we have many FreeBSD, OS X, Linux, and Solaris installations checksummed and cataloged. If you have other programs or distributions you would like to see in the database, please let us know."
Wouldn't this be useless to anybody that builds from source?
We need file verification, too! Probably more so with some of the Windows/IE vulnerabilities.
... when they trojan your MD5 checksummer? ;)
What if someone hacked into the MD5 database and changed the entries? :-)
-- Samir Gupta, Ph. D. Head, New Technology Research Group, Nintendo Co. Ltd., Kyoto, Japan.
This is the type of thing that you'd ask "Why didn't they do this sooner?" -- it's just that logical of an idea.
Absolutely fabulous, wonderful! The real trick, though, is to build up trust in your database so that those searching it will be sure that the checksums are actually correct--you know, rather than buying a burglar alarm from the robber himself. Thus, I doubt you'd be able to take submissions from users right away--at least without a competent staff checking to make sure they're correct.
I've been wondering when something along these lines would be available.
[devil's advocate] However, how do we know that the pregenerated checksums are correct? Who watches the watchers? [/devil's advocate]
Yah, yah, I know, the easiest way is to inspect the source for the minicompiler, the main compiler, and the program by hand, then build all of them step-by-step until you're done, then use the final binary to generate your hash. I wonder, tho, how much drift might there be in using a pre-built compiler (say I D/Led the binaries for GCC and the libraries to go with it). One tiny change in machine state (or any other number of things I would suppose) could result in the final binary being a single byte off, and the whole thing's a wash.
Granted, I may be talking out of my ass here, could someone w/ some hard-core coding knowledge or CS experience expound on the above?
Considering its history of vulnerabilities, I'd think that this would be pretty important...
...how often this will reveal distro's slipstreaming changes into a given version number.
The fancy way to do that is with an Authenticode-like system for signing files. Distro maintainers would sign the files in their distros, and users could also sign their own files. A simpler way would be to just have a big, signed list of md5's in some file that tripwire checks against. Tripwire would check the signature on the file before believing the md5's in it. Or the list could contain individual signatures per file instead of just hashes.
A centralized md5 database doesn't feel so right with the free software spirit, which says (legitimate) users could modify the files at any time, or just recompile them with a slightly different compiler, etc.
Other replies have mentioned that it might make more sense to boot off known clean read-only media, on which you also have a copy of your checksum utility.
That said, this still provides a false sense of security. The only way to be absolutely certain that your binaries have not been compromised is the following technique:
Have all your code written by hermit programmers. They must develop their OS and all programming tools (compilers, etc.) by themselves, on a computer that has no connection to the outside world. Taking an OS from another hermit programmer is also acceptable, as long as it is conveyed by hand from one to the other.
You must know and trust all of the hermit programmers.
The hermits must live, eat, and sleep in giant vaults designed to provide physical security to them and their computers. They definitely will not have telephones.
They must develop applications from scratch--no outside data may be allowed to contaminate their pristine systems. Source code may be imported, as long as it is delivered in hard copy form and hand keyed by someone who is very security conscious.
The hermits must hand deliver the binaries of applications to you. You should have already received a copy of their pristine OS by this method.
Presto! Completely secure binaries. No trojans. No false sense of security.
Oh, unless someone finds a buffer overrun that your hermits missed. Then some kiddie will own your box. Damn.
~Idarubicin
The reality of the matter is that, while it certainly would be possible for somebody to gag a machine to evade all your wascally checksumming tricks, they frequently don't do so. And when they do it, there's the usual arms-race lag between the time when a new method of checking comes out and when they update their tools to evade it. And there's a cost to them for each defense they evade; if you want to avoid every defense you ever hear of, you basically have to roll your own rootkits, which is a huge time investment.
And a kiddie who's out there collecting hundreds of boxes has no particular incentive to be anal about holding onto yours.
Fucking pompous amateurs.
OK - debian seemed to have one version there - r5, whatever that is. How does it handle apt-get upgrades? If r5 is reffering to something like stable, then even stable changes over time (contrary to what some poeple think ;-). So do they take the checksums from a machine that was just apt-get upgraded last night, or what? If they mean an actual yearly or half yearly release, who on this world does not apt-get upgrade when there is a security fix released? So your system sure as hell aint going to match theirs.
/bin /sbin, /usr/sbin etc - do they have some alternative to HTTP for their database?
Then I can't imagine how you would be able to automate this, so it checks all the binaries in
Doesn't seem overly useful to me....
Usually crackers don't think of altering the RPM database containing the MD5 hashes -- it's happened to me during a Bind compromise --, but there's nothing that would prevent them from doing so ... so you need an external database.
"Doesn't seem overly useful to me...."
/bin/* /usr/bin/* for all packages for all distributions for all releases, or when do older things get purged?
Nor to me, for a different reason: what about those of us with CFLAGS= set to various strange funky optimizations in Gentoo? What about the Ports system in FreeBSD, similarly?
This thing does not have the potential to spread to all distributions or all unixen.
What about historical storage? Are they really proposing to store an md5sum for
Seems mad to me. Would be better off staying with AIDE instead, IMO.
~Tim
--
Rushing on down to the circle of the turn
That's why rpms are not only hashed but signed (unlike this database)
Good luck faking the signature.