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.
You know, this is sort of cool... until it gets hacked (cracked... whatever) and then your entire OS looks bad. Wait. That is COOL!
3cx.org - A truly bad website.
Sounds like a useful idea, kind of like Sun's signed patches. Keeping up might be a challenge.
You might want to include source tarballs of important software, otherwise it won't be of much help to those of us who roll our own.
Would anyone know what field os study, what references, classes, or otherwise would be usefull in getting into Computer Forensics? Or, to specify, forensics of either computer crime, or finding proof to a crime within a computer. It's of great interest to me as it may be a direction I may be heading into.
Unique.
Put the cheksums for trojaned programs in the database, then crack the popular download sites. Who would know?
Subverting the meta-moderating system since 2003
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?
Oddly, a search of both FreeBSD 4.7-Stable and Red Hat 8.0 for "apache" or "openssh" yielded no results.
... what about a list of all checksums for a complete distro?
Either I don't know how to search, or instructions need to be posted on how to search! That, or
Considering its history of vulnerabilities, I'd think that this would be pretty important...
What they don't say and what a lot of security folks forget to do is that they can't check your checksums of binaries on the same box. You need to copy the files to another box and check the checksums there with a known good version of your checksumming binary. The local version of your checksumming binary could have been compromised.
Heck, the utilities you used to pull the binary off the machine in question could have been compromised and may not be actually copying the binary in question, but a good version of the binary. The only way to check this would be to mount the drive on another machine and check it there... And if people aren't doing that (which it's a pain in the ass) all this website is going to do is give people a false sense of security.
All editorial writers ever do is come down from the hill after the battle is over and shoot the wounded.
A few months ago I put together a list of the "polymorphic" files in FreeBSD 4.6:
These files are always going to set off alarms if you've upgraded-by-source. (On the other hand, if a file *not* on this list has a different checksum, it probably just means that you've applied a security patch.)
Tarsnap: Online backups for the truly paranoid
Boot from a known good floppy or CD to check your md5sums.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I'm working on a trojan md5sum program and it was getting suspiciously large because of all the md5 sums it has to contain. But now I just have to make a network connection to your database. Thanks a bunch!
That covers all the issues with keeping uptodate, from a 'trusted' source.. of course its no help for those not running Sun.. http://www.sun.com/solutions/blueprints/0501/Finge rprint.pdf
Get access to Suns database, or just drop it, and point Sun users to Sunsolve
I need a daemon that will monitor the binaries and check their md5 with this database to keep me secure!
While this is all well and good, it seems what would be better is a local utility that would allow scanning of the system for executables, etc. MD5 Hashes can be computed, and the results burned to a CD. This will eliminate the problem of different hashes due to things like timestamps, etc.
Still kinda cool, tho.
I never been so broke that I couldn't leave town.
Mu corporate www proxy filters this site as category "Hacking".
SunSolve
This is great for precompiled binaries, but it won't work so well for config files - they're different from system to system. I have a better solution:
/etc/passwd and /etc/shadow are especially likely to be modified, so I'd recommend sending those right away.
Anyone who wants to make sure their important config files haven't been changed by an intruder can email them to me, and I'll hold on to them for safe keeping.
have some Ajax (TM), you can get paranoid without even smoking anything!
C|N>K
This is completely redundant for RPM-based distributions. RPM's store MD5 sums and you can get these from the original istallation source. You can verif installed files from an uninstalled RPM.
Oh good, the md5 hash for my /sbin/md5 binary matches the signature found on known-goods. Now I can sleep at night. oh, wait...
_______
2B1ASK1
They should keep a database of md5 hashes of the database entries.
What about focusing on files that are routinely replaced with trojans, rootkits, etc.?
I'm not saying NOT to do the rest of the files, just that these (I'd think) would be the files that you'd want to check FIRST before the rest of the system.
Perhaps a separate section featuring these targeted areas?
...how often this will reveal distro's slipstreaming changes into a given version number.
The known md5 hashes database might get hacked, so your fresh install appears to have been hacked even before you put it on the net! Pesky hackers.
WASHINGTON (AP) -- Academy Award-winning actress Elizabeth Taylor and Grammy-honored singer Paul Simon were among five stars from the world of performing arts being honored Sunday for their career achievements.
Joining them at a White House reception before a gala at the nearby Kennedy Center for the Performing Arts were actor James Earl Jones, actress-singer-dancer Chita Rivera and conductor James Levine.
President Bush and first lady Laura Bush planned to attend the 25th annual program where the careers of this year's honorees are celebrated.
The Kennedy Center's chairman, James A. Johnson, called Taylor "a luminous film actress who for nearly 60 years has been a Hollywood icon treasured by millions throughout the world."
Taylor, 72, became a child star with "National Velvet" in 1944 and later won Oscars for "Butterfield 8" in 1960 and "Who's Afraid of Virginia Woolf" in 1966.
More recently, she has helped raise millions of dollars to fight AIDS.
Simon, 51, was added to the lineup in August when, a few weeks after the official announcement, former Beatle Paul McCartney withdrew because of a personal obligation.
The Kennedy Center said McCartney would be on the 2003 list and that Simon would have been honored in the future.
Simon first became known as part of a duo with Art Garfunkel. "Sound of Silence" and "Bridge Over Troubled Water" were among their most popular numbers.
The songwriter helped shape several generations of young Americans, Johnson said. "More recently, his work has encompassed an awareness of and concern for international art and artists," he said.
The other honorees are:
Levine, 49, longtime musical director of the Metropolitan Opera and now leader of the Boston Symphony Orchestra, was credited with bringing "one of the world's foremost opera companies to unsurpassed artistic excellence."
Rivera, 69, "a musical theater star of the highest magnitude." She is a two-time Tony Award winner.
Jones, 71, "an actor whose extraordinary range and power have made him an American institution." The voice of the evil Darth Vader in "Star Wars," his long and varied career has produced two Tonys and four Emmys.
The first Kennedy Center honors in 1978 named singer Marian Anderson, actor and dancer Fred Astaire, choreographer George Balanchine, composer Richard Rodgers and pianist Arthur Rubinstein.
The program airs December 27 on CBS.
http://saveie6.com/
do any of the distributions allow for doing something like this via apt/dpkg?
.rpm/.deb but it seems like something workable for the binaries that are installed.
likely only handle part of the
members are seeing something, your seeing an ad
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.
club!
Debian has this built into the OS with debsums.
It does require a legit dpkg database (and md5sum, and the debsums program itself...) but it's a nice tool.
This sounds nice, but I see problems as installs move from the "100% installed code" to the "patch of the week" versions. Especially when you have to do custom builds of the software.
/bin/ps on a few local systems. (If you don't know why I started with this one, you will. Probably sooner than you'd wish to.)
Are you running BIND, Apache, wu-ftpd, or (shudder) Sendmail? If you are, your system won't be entirely in their shiny dbase for more than a month (probably more like a week) after you install. And if _you_ don't update it, someone will be kind enough to "update" some file for you soon enough...
As a test, I checked
From the dbase:
RH 7.1 - MD5: ac0b58050deb21db1ed701277521320b
RH 7.3 - MD5: 6d3abf4efc9235e4eb5dc540d61d42fa
My systems:
#1 - MD5: ac0b58050deb21db1ed701277521320b
#2 - MD5: ac0b58050deb21db1ed701277521320b
#3 - MD5: 9724525265900e5f9020de3b431425b1
#4 - MD5: 881c7af31f6f447e29820fb73dc1dd9a
#5 - MD5: 6d3abf4efc9235e4eb5dc540d61d42fa
Binary compatibility is seen for systems 1, 2, and 5, but the RH7.2 system (#4) doesn't match. System #3 is a Gentoo system, which is probably the most secure, but also the least likely to ever match with their list. I guess that's the peril of compiling your own code.
Turambar
------------------------------
Common sense is not so common.
--Voltaire
I'd rather see everyone using bitzi.com, since it's
goal is to gather metadata for *every* file in the
universe, and keep the data free, supported by a
related business model (and a viable, sustainable
support mechanism is GOOD), but I support this
project too, because choice and freedom are goods.
Therefore, I urge everyone to submit metadata
to both projects.
If you only submit to one, however, please submit
to bitzi, because it provides an automation API,
and uses better hashes.
Note that I have no affiliation with the Bitzi company.
-I like my women like I like my tea: green-
NIST (The National Institute of Standards and Technology) currently has a program to provide this service, though largely focused on Microsoft OSes and associated apps. It may be found here: National Software Reference Library
The complete list of software they've checksummed can be found here: Software Listing or you can use their search engine if you're looking for a specific application here: Search Engine
Something to combat md5sum itself from being cracked. Perhaps a statically compiled binary that you can download with the program of your choice. Then rootkits would have to modify every program that can download a file, or the kernel. The best system would be a nice bootable CD that would scan all known file system types for files that have md5 sums of known bad files, not search for files and make sure they have a md5 sum of a good file. Then root kits will have to rely on a compiler or append random bytes to the end of the files.
Well this gets so complicated that by the time you've thought it all out, you really need virus scanner technology to thwart root kits. Maybe a kernel patch could run a virus scan on executable files? It would be quite difficult to tamper with the actual running kernel in memory without causing the system to lock or reboot, thus giving away that the system is being tampered with. Assuming root kits are distributed in source form, you'll need heuristic scanning to find them. This means false positives and manual overides by the system administrator.
Karma Clown
Ideally, a simple tool should be developed that does the following:
Compare the MD5sums of critical files to a recent known "snapshot" of the system on RO media, which only indexes files that were changed and reconciled. Perhaps there is a list of files of which only certain byte ranges (perhaps just executable ELF sections) are checked, are some are omitted. (Other slashdotters mention caches/timestamps in certain relevant files that screw up checksums). You would have a whitelist (files which must match), then a graylist (files which meet byte-range criteria), and perhaps even a blacklist that prevents files that would normally be flagged to be ignored.
In checking full file checksums, those not explicitly listed above would fallback to a check using a HTTP get request conforming to this helpful document these guys have offered.
And to those who were asking about other distributions: they are looking for people willing to work with them to add new distros/architectures to their database.
Fuck Beta. Fuck Dice
(Copied from my earlier post)
NIST (The National Institute of Standards and Technology) currently has a program to provide this service, though largely focused on Microsoft OSes and associated apps. It may be found here: National Software Reference Library
The complete list of software they've checksummed can be found here: Software Listing or you can use their search engine if you're looking for a specific application here: Search Engine
I had my Linux 6.0 broken into and ls binary was replaced together with md5 checksum generator so it was really hard for me to find out.
NIST does this too. For a different reason though. To help forensic examiners eliminate non-important data in a suspect's computer. They use 4 different hash algorithms (MD5, SHA-1, CRC32, and one other), so good luck finding a collision for all 4. They were giving out copies of the CD-hashdb at an InfoSec conference I was at recently.
Cheers
Tripwire
Backups are for wimps. Real men post their data in comments and have slashdot mirror it
Had you been running SE Linux your files would not have been modified in the first place and a good audit trail would tell you what they attempted to modify.
How about this kind of database for media files for P2P networks? P2P clients could check the file to see if it was "genuine" or an RIAA-induced dummy file.
Now I can add a compromised md5sum to my rootkit which uses values from this site.
Go team!
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.
For Red Hat-based systems, at least, rpm -V will do pretty much exactly what you're looking for.
... The (mnemonically emBoldened) character denotes failure of the corresponding --verify test:
/etc/php.ini
/etc/httpd/conf/httpd.conf /var/www/html/index.html /var/www/html/poweredby.png
:)
From the man page for rpm:
The general form of an rpm verify command is
rpm {-V|--verify} [select-options] [--nodeps] [--nofiles] [--nomd5] [--noscripts]
Verifying a package compares information about the installed files in the package with
information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, MD5 sum, permissions, type, owner and group of each file. Any discrepencies are displayed.
S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mis-match
L readLink(2) path mis-match
U User ownership differs
G Group ownership differs
T mTime differs
So while that's a bit cryptic, a shell script run once every x days (30? 14?) should tell you what files have changed. All you would have to do is run rpm -qa to grab a list of the packages in your system, and then loop through the list and run rpm -V for each RPM returned.
For instance, running rpm -V on two common packages, Apache and PHP, shows me the following:
# rpm -V php
S.5....T c
(php.ini has changed... which in this case means I've tweaked some of PHP's default settings.)
# rpm -V apache
S.5....T c
missing
missing
(Okay, I've changed httpd.conf, again pretty much a given, and I've removed a couple of the default files.)
I guess this website seems pretty unneeded to me. Granted, the above is just for RPM-based systems, but I'm sure Debian and ports have similar options. And to the people who have installed from source and say "What about me?", I say, first, never underestimate the power of a package management system, and second, check out CheckInstall, which allows you to create an RPM or DEB just by saying "checkinstall" instead of "make install". If you feel you must compile from source, checkinstall is a necessity! Using checkinstall gives you all the benefits of a package management system while still allowing for the flexibility that compiling from source provides.
Between checkinstall and up2date, I'm a very happy Red Hat customer. I just wish more people knew about some of the truly powerful things in package management systems (such as the verify command detailed above.) Package management systems are there for a reason. Use them!
Simpli - Your source for San Jose dedicated servers and colocation!
The problem with this is that it assumes that binaries never legitimately change. That is false in Mac OS X. The Mach-O file format allows for "pre-binding", where the linker tries to resolve imported functions and data before the app is loaded, and, if successful, writes the offsets to the file.
I'm not familiar with the Mach-O file format, but I'd guess that the changes are confined to a small part of the file. But if you could just checksum the code sections, that might work.
On the other hand, talking about libraries makes me think. Don't forget to check the libraries. If I trojan libc, I'll be getting all kinds of control while leaving the program binaries unmodified.
rlwimi
'nuff said
Ok, lets see if I've been hacked... /dev/null
/dev/null with /private/var/servermgrd/servermgr_dirserv.lock from Mac OS X. What a bummer and its a brand new system too...
$ md5
d41d8cd98f00b204e9800998ecf8427e
So I put d41d8cd98f00b204e9800998ecf8427e in the search engine and it came up with 560 hits (compared with 3170 from google).
Now it appears that someone replaced my
Does the database have a way to flag files as being bad? Sa
When I put in 3ac9bc346d736b4a51d676faa2a08a57
I should get back:
*** Trojaned openssh-3.4p1.tar.gz ****
One thing that could make this useful would be a dns like interface...
host 3ac9bc346d736b4a51d676faa2a08a57.knowngoods.org || echo bad
Sun already provides this for Solaris.
s .p l
http://sunsolve.Sun.COM/pub-cgi/fileFingerprint
It contains information for:
Operating Systems
Solaris SPARC - 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 2.6, Solaris 7 and Solaris 8
Solaris x86 - 2.1, 2.4, 2.5, 2.5.1, 2.6, Solaris 7 and Solaris 8
Solaris PPC - 2.5.1
Trusted Solaris SPARC - 2.5, 2.5.1 and 7
Trusted Solaris 7 x86
Most CDs bundled with Solaris 2.6 and later.
Patches
Nearly all released Solaris patches, including all SunSolve CDs to date. (4.0.11)
All Solaris 2.6/7 Maintenance updates.
All patches available from SunSolve.
Unbundled Products
Around 150 CDs with unbundled products are included. If you are missing any particular product, please feel free to send email and we will try to include it as soon as possible.
Those who want to give you their files for safekeeping should not forget to include their ip addresses, so that you can contact them in case of a problem...
A MAC is like a hash with a secret key; the hash depends on both the file and the key. That way you can keep a copy of the database locally and an attacker can't change it to cover his tracks like he could an MD5 database if you kept it locally (of course he could change the verify program if that were local...but probably not without changing the file size).
This would allow for protection of files not in an online database (compiled from source, for example) using only local files.
You can use a block cipher chaining mode (don't remember which one) as a MAC, or use say AES_k(MD5(file)), or, IIRC you can use MD5(k_1 file k_2) where k_1 and k_2 are different secret keys (check this out before using, lots of constructions like this are totally insecure), or you can use something designed as a MAC (eg RIPEMD). Any of these could be run from a shell script to quickly verify all binaries (or whatever you were protecting).
I hereby place the above post in the public domain.
I like this utility. It's pretty handy, although probably not as effective as this database, unless you're running slackware, or another popular, but undatabased distro. :-)
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
What release exactly does Linux Debian r5 refer to? Debian numbers their releases #.# with security updates appended with r#. Are they refering to 2.2r5, which is Potato with known security holes[since Potato's last security release was 2.2r7], not exactly what paranoid people have on their system[and Woody isn't even at r1]. And with arch are the md5sums supposed to be for since presumably every arch would have a different md5sum[you would assume i386, but nothing says for sure on the site]?
the poster mentions Tripwaire, but what about AIDE?
In additon to being a proper Open Source project, it allows for features that (last I heard at any rate) tripwire doesn't support, like a centralized checksum DB. That feature alone makes the tool superior (IMHO). For example it makes the verification process a lot nicer (intruder can't courrpt the local md5sum's because there aren't any).
(n/t)
sir that is a sick web sight and you should be illegal for linking to it! what kind of a world is this anyway. that sort of material is sick and wrong and should not be a part of a decent world! bess armstrong was in jaws three.
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....
I found a fairly straightforward solution to this problem. I wrote a small wrapper around a known-good md5 function, compiled it and placed it in a nonstandard location. (Thus it doesn't have a widely recognizeable filesize or md5 to be detected and stomped) Then I wrote a simple shell script which checksums various critical files on a regular basis and tests the MD5 values against a record it keeps, again in a private location. Whenver a change happens, it sets off alarm bells all over the place, both in syslogs and on the console.
/etc/crontab, then checking each local shell script for a sensor and carefully overwriting my own nonstandard code - but if any attacker has that much free time on his hands, there's a limit to how much of a sensor I can implement.
On top of this I stuck in one small bit of shell script that allowed me to modify a file myself without setting off alarms - it simply recalculated the md5 value and updated the record files.
I suppose this is theoretically vulnerable to an attacker reading through
The nice thing about this code is that it also implicitly tests for corruption of critical files after fsck-triggering events like kernel panics or total power failures. (That's actually what prompted its initial writing) And it's remarkably trivial to implement, even more so if one simply copies an off-the-shelf md5 binary rather than compiling one's own wrapper.
I checked various executable files on OS X 10.2.2 6F21 and got checksums different from the "known good" ones.
In Soviet Russia... we can buy a new car for $2.
for that reason, I would add entries of my comprimised binaries instead of altering the existing ones.
External database?
Um...no matter what verifications you use, you need to have a database of them. external has no meaning here; it could be on a disk, cd, diskette, other partition, data server, etc
These files can contain trojan too, and most "modern" trojans are written in some interpreted script, not in C. How about detecting this?
MSDOS: 20+ years without remote hole in the default install
You forgot handing out free sandwiches while not wearing any pants.
2. ???
3. Profit!
Our company's slogan is "Give us money, we'll do stuff"
I was dissappointed to see no OpenBSD database. :-(
Simple. Say RH has md5 sums on their rpms. Say this site shows 'em too.
If someone attempts to fux0r some software, either site will show it.
If someone fux0rs one site, the other will show a difference, sounding an alarm.
Of course, one could hit the software before it's released at all from the vendor, but this wasn't
really meant to protect from that.
In short, this is a novel idea to have more eyes watching. More eyes == good.
"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
Those who want to give you their files for safekeeping should not forget to include their ip addresses, so that you can contact them in case of a problem...
Sounds like a good idea, but that's all you can get for free. I have limited space and resources -- I can only keep track of so many password files and IP addresses at a time at no cost.
Erpo's "Bronze Tier" security service is available for $10 per month, and for that modest fee you can have the privilege of running Erpo Inc.'s backdoord, "The most advanced intrusion detection software on the planet." (Note, UID 0 and internet access necessary for security functions to operate effectively.) For those willing to spend $50/month for a little more peace of mind, Erpo's "Silver Tier" plus package includes eight (count them, eight) bytes of space on my hard drive for a cleartext backup of your root password. Sometimes, however, that just isn't enough. For those that need the ultimate in security, Erpo Inc. offers the most comprehensive option available anywhere: the super duper "Gold Tier" uber-premium technoblaster package with cherries on top. Clients in this elite class of service have the extreme honor of keeping their servers on-site in a musty corner of my basement (T3 and battery backup provided by client, some restrictions may apply, void where prohibited). For only $100/month, I will personally look through all of your sensitive, private data to make sure it has not been compromised by an attacker. It doesn't get any better than this, folks. Sign up today at www.er....
What? Fraud? Don't be silly.
That's why rpms are not only hashed but signed (unlike this database)
Good luck faking the signature.
A problem with the known-good-database is that it may not contain the distribution you actually use (e.g. if you use an updated SuSE 6.4, you will never know if your /bin/ls is that of SuSE 7.2).
If you have two boxes with the same distribution, and you are quite sure, that they have not been hacked the same way, you can easily compare the md5sums of those two.
It seems counter-intuitive to enforce a local security matter to an external interface source.
Larger business have to overcome the security risk of false positives (what if an obscure applications hash changed?).
Also what authentication system protects man-in-the-middle? SSL? What integrity system protects this single point of failure? Why don't I just use that?
Seems like a lot of trust (too much?) is required on the users part.
Create a Knoppix (http://www.knoppix.org) CD that
1. Determines checksums for everything on your system (including the BIOS), then
2. Burns a new Knoppix CD with the checksums.
Is there a way to embed a valid checksum/digest inside a file? I mean if you calculate a checksum for a given file and add that checksum at the end of the file, the new file checksum value would then be invalid (caused by the presence of the checksum at the end)...
Aren't MD5sums 1024-bit? (This may be incorrect. Check it if you like, and tell me I'm an idiot if I'm wrong). You said yourself that you didn't know how much junk. I daresay that's quite a bit, to put those sums in the same place.
Of course, I could be utterly mistaken. Boo me.
From their list:
0327. Crack for OS/2 - 4.1 - UNK -- Unknown
Do they checksum cracker tools? Why?
Well, one could embed to the hash the hashes of compilers and sources used. And once the final hash is built, sign it with a public encrpytion key to ensure that the hash is good. But I think that there is no easy/feasible way to ensure that files are good. Just guessing...
The only secure way to use the verification tool is to boot from a readonly media and run the tool from there.
The black hats have trojaned, and will continue to trojan, a machine's flash BIOS.
Will I retire or break 10K?
Do you list the gentoo binaries there, too? :)
A while back I was attempting to brute force the MD5 hash of a forgotten password, and when I read the slashdot story about this database, an idea occured to me.
Currently on a fast PC, it takes approximatly 400 days to test an MD5 hash for collisions with strings up to 8 days in length, and using the charset a-z,A-Z,0-9.
What is these were precomputed and stored in an indexed, searchable database. It would take a while to compile such a DB, but with the aid of parallell proccessing, or perhaps a distributed broject similar to SETI@home the time could be reduced.
If this was created, people could just enter an MD5 hash, and in a fraction of a second get back a list of known collisions. Makes you want to rethink MD5 passwords for security.
Has something like this been attempted before? Is something like this even possible (I imagine storage space could be forbidding)?
I use a database of MD5 hashes to match my hard drive's files against backups. I tried to make a Sourceforge project out of it, but lost interest because of the trouble with polymorphic files, and especially the trouble of matching all files in non-standard installation archives (damn setup.exe files).
I named the project Filepedia originally though because I thought it would be nice to have an online encyclopedia that could tell you information about a file based on its MD5. Still doable...
So, mathematically and cryptographically sound hashing alogirthm used to provide a database of hashes from persons unknown using a plaintext transfer protocol with no data integrity... or have I missed the point again ?
The National Software Reference Library is at http://www.nsrl.nist.gov/
Which goes another step further, and stores not only the checksums, but also copies of the file data centrally, so you can undo changes that have been made. OR you can change the data on the central server, and effectively push out updates to hundreds of machines. That's RadMind
:wes
The National Software Reference Library is at NIST.
Not only that, but when you install a package with the sun pkgadd tool (like RPM, only not for use by the unwashed masses), it drops package checksums into your spool directory. You can verify checksums of every damn file you've ever installed with pkgchk -c....
I have yet to see a root kit which modifies this checksum [although it could happen], but going to the master checksums is certainly not hard, and pkgchk -c is so nice and easy.
Do daemons dream of electric sleep()?
Many (most?) of the OpenBSD users I know have custom environments, the first thing they do with a new release is 'make world', resulting in all new binaries with checksum signatures unique to their environment.
I've been privately building up a database of "known bad", MD5/SHA1 signatures from known examples of trojaned binaries, worm DLLs, and the like.
I do not deploy Linux. Ever.
IN SOVIET RUSSIA tongue's got your cat!
It's always a long day... 86400 doesn't fit into a short.
AV companies don't develop or relase viruses, for the simple reason that all hell would break loose if they did (and theres the morals and ethics or course
The AV research community is composed from many elements and there are plenty of people who work for universities or other non-comercial parties. So no big dirty secret would stay as a secrect for long. And then theres the matter of competiting companies, and being able to catch a competitior from releasing a virus would be about the best way to shoot that company down.
Just someone who has been working on the field for couple years....
thats right, i'd love to see windows checksums listed
then just save a known-good copy of your /var/db/pkg. You can check md5sums agains it with the "qpkg" tool from the gentools ebuild.
----
All of whose base are belong to the what-now?
OT but, as someone who has worked for years in software support, I can tell you that checksumming is not a final answer by any means to tamper notification. These tools can be of more concern for someone who doesn't know what their doing than they are worth...
I was lucky enough to receive the customer call when his binary had a changed checksum. The customer was very obviously concerned about this as it was the primary executable for our software. "What trajons are there for this?". My answer, "None known sir." did not elicit any confidence. A few minutes and a diff check later, there was one small bit of corruption that had occurred in the file. It was obvious too little had changed for the executable to have been altered, so I told him to simply restore from his back up.
Point being is that just because an MD5 checksum is off means little. Integrity checking should always be a part (and only a small part!) of a more substantive system of security.
Another idea maybe to have a program that compares md5 checksums between a number of computer systems on a network instead. Considering most people will deploy the same OS and alot of the same version binaries across a bunch of there servers, couldn't the network as a whole be used as reference instead of a database?
I'm actually thinking of adding this ability to my current software project Pushchange.
You don't understand that while perfection may not be possible, there is nothing wrong to point out the imperfections.
That's a pretty large ego you've got there for a guy who is willing to settle for less. You don't even seem to want to work for a better solution.
You speak with such superiority when you fail to even point out good solutions like booting from known good read only mediums. Heck, even the anonymous cowards had something better to say.
You've added nothing.
All editorial writers ever do is come down from the hill after the battle is over and shoot the wounded.
Given that file checksums are used to provide a reasonable guarantee of authenticity, if you use someone else's copy of the checksum, you also need a reasonable guarantee of that third party's integrity for the checksum to have any value. There used to be a warning that came with PGP about this very thing: keys are worthless unless you can trust the source of the key.
That said, there is no information about their underwriters on the KnownGood website. Until an explicit, verifiable guarantee of not only KG's integrity but the integrity of their database and the checksums it contains is provided, I won't trust them in the slightest. For that matter, who could underwrite them to provide these guarantees? Lloyds of London?
it should be required at least to move a jumper to flash it.
So you have to open your computer's case just to flash the BIOS? Sure, requiring physical access is good and all, but novice users do not want to open the computer for fear of breaking something. When designing secure systems, remember that the Internet will always contain machines administered by home users with no clue as to how to run them.
Will I retire or break 10K?
How do we know knowngoods is not compromised? Or how likely it is to be compromised? There is no information on how they ensure security of their site, etc. The fact they left this out seems quite damning in the light of what they are claiming to do. For all we know they could be far easier to hack than the other source sites.
You probably need at least two different sites running different mechanisms. In fact the second site should be just a plain static webserver, everything else turned off. Forget the PHP, SSL etc. HTTP static serving is fairly easy to get right if you leave out the extras.
We can use symlinks of course... syslogd would be a symlink to syslogp and
ftpd and ircd would be linked to ftpp and ircp... and of course the
point-to-point protocal paenguin.
-- Kevin M. Bealer, commenting on the penguin Linux logo
- this post brought to you by the Automated Last Post Generator...