Known-Good MD5 Database 309
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."
What about source builds? (Score:5, Insightful)
What?! No Windows? (Score:2, Insightful)
But what happens... (Score:1, Insightful)
So what about the obvious scenario... (Score:2, Insightful)
This is one of those things... (Score:3, Insightful)
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.
ooooo nifty (Score:5, Insightful)
[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?
What about Windows OS? (Score:5, Insightful)
Considering its history of vulnerabilities, I'd think that this would be pretty important...
Re:So what about the obvious scenario... (Score:4, Insightful)
Re:What about source builds? (Score:5, Insightful)
Indeed; the capability of such a system is a bit limited with operating systems like FreeBSD, which actively *encourage* their users to build/rebuild from sources. IIRC, FreeBSD actually only gives intermediate security updates in source code format so you have to compile them (not too hard: cd /usr/src ; make buildworld).
So, recording the checksum to /bin/ls, etc. is a bit flawed in that when I do a "make buildworld", my custom configuration parameters from /etc/make.conf get used, overriding CPU type, if Xfree86 is installed, etc. Since my system's parameters likely will not match FreeBSD's master build system, there is a high chance that the checksums after I do a rebuild are significantly different.
But for non-source distributions (Redhat, etc.) this concept is excellent, assuming that no one compromises the database or the OS kernel. Unfortunately, no database checksummer will ever counteract the case when the OS kernel itself is compromised, potentially returning one file when scanned and another when executed.
Still, it wouldn't hurt for them to record source file checksums as well; after all, having an independant checksumming group would require them to be compromised as well as the FTP network, making an attacker's life harder.
Re:What about Windows OS? (Score:3, Insightful)
You can't compile a explorer.exe with a nice back door added in unless you've got the source to explorer.exe.
Of course you can - it is trivial to alter the behaviour of a Windows executable; viruses do it all the time.
Append the backdoor to explorer.exe, fiddle with afew bits so the backdoor gets executed first, and find a way to drop it onto the system.
Re:What about Windows OS? (Score:4, Insightful)
Also, can't people still use disassemblers to 'crack' files, and maybe add backdoors at the same time?
Both of these activities would be reflected by checksum changes.
Re:What about source builds? (Score:4, Insightful)
In fact, this system would be best suited for systems which aren't OSS... such as windows =)
crowd boos... stones and rotten tomatoes fly as author runs for cover
I have to wonder... (Score:1, Insightful)
Something's wrong here (Score:5, Insightful)
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.
Re:Compromised /bin/md5 (Score:3, Insightful)
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.
"False" senses of security (Score:5, Insightful)
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.
Re:What about source builds? (Score:1, Insightful)
Re:What about source builds? (Score:3, Insightful)
Re:But what happens... (Score:4, Insightful)
Then your compromised system might apear to be clean. I have actually seen a system where that has happened. But the intruder forgot to trojan the rpm executable, "rpm -Va" revealed everything. But had the intruder trojaned the rpm executable too, that wouldn't have worked. The only secure way to use the verification tool is to boot from a readonly media and run the tool from there.
Re:What about source builds? (Score:3, Insightful)
Because the default /bin/ls is lowest common denominator. As for a waste of time...
I can afford the 1.59 seconds.
sh
Versions? (Score:4, Insightful)
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....
Re:What about source builds? (Score:3, Insightful)
Re:Er, rpm -V? (Score:3, Insightful)
Re:But what happens... (Score:2, Insightful)
That way, at the first sign of trouble, you just toss in the disk of known-good tools, with the confidence that at least that stuff is clean. Yes there are ways other than this, I'm sure, but for us non-super-guru types, it's pretty handy.
Source distros! (Score:3, Insightful)
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.
rpm = MD5 + GPG (Score:1, Insightful)
Good luck faking the signature.
Re:"False" senses of security (Score:2, Insightful)
Re:"False" senses of security (Score:2, Insightful)
If you suspect a breakin, schedule a half-hour of downtime and boot from a trusted CD, like Knoppix or the live filesystem that comes with Slackware, and check your HD from there.
And if the BIOS is trojaned?