Ok, I just noticed that Process Guard actually uses md5 checksums of executables for handling signatures for "known" programs. Sorry, but I am really, really disappointed by this. Md5 has been proven completely broken for more than a year now. There have been proof-of-concept demonstrations of just how broken md5 is, for X.509 certificates (http://eprint.iacr.org/2005/067), executables http://www1.corest.com/corelabs/projects/research_topics.php?, meaningful documents http://www.cits.rub.de/MD5Collisions/, and there are tools for creating collisions in a really brief time on a common notebook http://eprint.iacr.org/2005/075. If you don't believe this really affects Process Guard go ahead and try using these two executables: http://www1.corest.com/corelabs/projects/research_topics/Richarte_md5-2-collisions.zip. Try permanently allowing one and then replace it with the other different executable. Process Guard won't complain that the exe changed at all. I just don't understand why Process Guard actually still uses md5 instead of something like sha256 or sha512 (sha-1 has been proven broken as well, however NOT NEARLY as broken as broken as md5). Not only md5 is broken now, but its weaknesses are going to become trivial to exploit in a very short time (if they are not trivial already).
Hmm.. this is actually quite interesting to me. I had no idea how "weak" MD5 was. When I looked at a Hex compare of those two apps they were indeed significantly different. I wonder what the performance hit would be for calculating a SHA-256 hash vs. an MD5.
I'm sure PG will move to SHA soon, however this is not really a vulnerability as such. It would actually however be VERY hard to create an executable you can attack PG with. Care to demonstrate one ? First, you need to know a process which is on the target PC, allowed to run permanently, AND has the desired ALLOW options in the protection list. No point if it can run, but then can't DO anything. Your trojaned version of the file must remain functional, so as not to draw attention to itself. It must also have the functionality to then compromise the system. This program also needs to be replaceable, so it cannot be running when you send over the new one. Doesn't sound so easy now, does it ?
Good to hear that this will be addressed. It's true to say it is not yet a vulnerability - what has been demonstrated is the ability to find two files which resolve to the same MD5 checksum, for it to become a compromise it would be necessary to find a file with the same checksum as an existing one (a pre-image attack). However a pre-image attack is the next step so changing to SHA256 now would certainly be a prudent move.
Well collison attacks can in theory hurt you as much as preimage attacks. For example, the attacker might prepare two files that have the same hash using this attack, one is a perfectly clean file with some useful function- some freeware for example and another is a trojan. He then offers the first file for free on his website. Using the freeware and giving it permissions would mean giving the same permissions as the trojan right? So the next time you update it, maybe an autoupdate in the same place, he replaces it with the trojan. And he's home free, the trojan would be free to at least start without your permission, and probably a lot more depending on what other previlages given. Though of course if you are sharp, you might wonder why an update didn't trigger a hash check. A (second) preimage attack would be even worse, since he doesn't have to induce you to use and accept the first file. He will probably target some commonly used file and make sure his program has the same hash as that. Still all this seems very far sketched to me, but it's possible.
TNT, it's really not as hot as you might think. An attack consisting of a creation of a malicious program with an arbitrary (runtime generated) MD5 hash is still computationally unfeasible, and nothing suggests that this situation should change in the near future...
And totally improabable too. If an attacker could lure you into downloading his file in the first place, why bother with a non-malicious one? It would make more sense to include the trojan with the initial download and provide some reasonable explanation ("It's a security app guvnor - it needs ta do wossitsface to your antivirus and firewall to 'elp them along...") for granting it privileged access (or bundle it with PunkBuster...).
Sure but you would likely to be very supicious at first. You would do all sorts of things to check if it's okay, run it in vmware or something similar with restricted rights, check it with a full battery of antivirus , look at it with a hex editor and more stuff ten i can name. The point is to lull you into a sense of what's the word, gain your trust as you give it all sorts of permissions and then spring the trap. So maybe you had this nice little app for ages , it works as advertised, Then they do a bait and switch.
An attacker can "build trust" with a standard trojan containing a conditional or delayed payload (like most viruses have) - there's little point in them making the extra effort of creating a second download with a matching hash, especially when the vast majority of users (and most compromises aim for the more numerous "low hanging fruit") aren't using any hash-checking execution-blocking software.
Trojans that carry their payloads (delayed or conditional) with them could be possibly sniffed out before they have the chance to gain trust. But if by conditional you mean it replaced itself it only after a certain amount of time, it could be probed as much as you like and still be seen to be clean. Strange logic, since in this case we _are_ talking about people using hash checking execution blocking software. And obviously I'm pointing out a scenario in which such defenses can be circumvented. That's the reason for this thread after all. Granted people using such defenses are rare, but that's hardly the point.
Or... Bob developed a little server application for the company he works with. However, Bob has been in contact with another company for a new job for a couple of months; now, the night before he leaves for the new company, Bob substitutes the executable for the server application with one carefully developed containing a backdoor but resulting in the same md5 checksum; and the system administrator had given Bob rights to upload his files only in that directory. Being a paranoid (), though, the system administrator had even compiled the executable himself and stored the md5 checksum on his private HD to check. Now the system administrator put faith in the fact that if the executable had been replaced, it would be noticed. After all, if Bob had replaced the executable the night before he left, it would definitely look suspicious. In reality, it goes unnoticed, even though the old one is clean and this one has a backdoor.
Then perhaps you should look at more obvious and exploitable issues like the RunDLL32 one - or an attacker coding their wares in Java. These are far more plausible options and PG will only flag these if users have chosen to Allow Once for rundll32.exe/javaw.exe which most won't. Riiight...a server admin that relies on a complier to look for backdoors? One paranoid enough to take checksums manually but trusting enough to accept a new code version on the eve of a programmer's departure without doing a diff on the source code? Not to mention a company seemingly lacking a source code control system. I'm sure that there be one-in-a-million situations where MD5 can be exploited using post-image attacks, just as there will be occasions when people will get kicked to death by an angry goat when crossing the road. However the view that most should take is to focus on the most likely (and practical) dangers and protect against those - like looking out for cars when crossing a road rather than goats (or goats driving cars).
What does this have to do with the compiler and source code? The admin doesn't have the source of the trojaned executable, only the source of the clean one. Who said the programmer even did it at work instead of programming the trojaned executable at home? Just take the previous example of the two executables with the same md5 hash... who said the programmer had to tell the admin that he had "a new version"? I never did, nor did the little story... nor did Bob the programmer, and that is the point: since the programmer can upload the binary himself and the md5 doesn't change, if the admin completely trusts that the md5 changes if the binary changes, he won't notice that it has been replaced. I can't believe you think this situation is so unlikely. You know, I am a programmer and if were able to make two executables with same md5 checksum I can tell you that I would probably be able to put in place a similar scenario right now (not that I would do it, but).
Said prudent ADMIN would check with a HASHING specific tool ? one which hashes all files not just executables and DLL's I would, if relying so much on checksums. It would use SHA-256 minimum ! He would also see the change in his logs if he allowed access. However I do agree somewhat with the previous basic outline that an executable could be done like this. SHA-256, 384, or 512 are the likely choices for future hashing in PG. I'd suspect we will go with one of the higher ones.
