Malware: certified trustworthy

Do we have a big problem with the right-management of Vista´s security-model?
http://www.h-online.com/security/news/item/Malware-certified-trustworthy-Update-1027066.html

Do I understand it correctly - the TrustedInstaller would accept the missleading cert and install any application without a peep?

http://www.h-online.com/security/features/SSL-for-free-step-by-step-906862.html
http://msdn.microsoft.com/en-us/library/ms537364(VS.85).aspx

 

I guess so, I've got samples of malware that pass all authenticode validation methods.

 

I read through the PDF that was released by F-Secure and I find their conclusions to be a bit far-fetched. The PDF outlines 8 possible attack scenarios relating to digital certs. They are:

1) Copying Certificate information from clean files
2) Selfsigned certs with fake name
3) MD5 forgery
4) Get certified and be evil
5) Get certificate with misleading name
6) Find someone to sign your stuff for you
7) Steal a certificate
8. Infect developers system

Options 1 and 2 are both completely stupid, and as the author himself admits, attempting these would cause the software to fail authentication anyway. Basically, these attacks do not work and their inclusion here only illustrates how much of a FUD piece this PDF really is.

Option 3 relies on the flawed MD5 hash which no one should be using anyway. Everyone I know who signs software uses SHA-1 or better. Besides, even if using MD5, the author admits that finding collisions is very difficult for a file of any size whatsoever.

Option 4 is not a flaw with digital certs! Digital certs were never intended to provide detail on whether the code is malicious or not. The purpose of the digital signature is to authenticate from where the code came from. You can verify that code came from Microsoft, but if Microsoft has a rogue developer working for it, then the code could be malicious. A digital signature does not solve this issue, nor was it intended to.

Option 5 is nothing but a social engineering attack and does not exploit any physical flaw with digital certs. If the user takes a minute to verify the REAL signature of company X or developer Y and then compare it to the cert on the software with a "misleading name" he will see that it does not match. Indeed, this process is usually automated and the user shouldn't have to do anything but watch as the malicious file fails verification.

Option 6 requires a malicious developer to be working for a legit company. This would require the malicious developer to have access to the private signing key (something which very few people have) and then sign the malicious package with it. A far-fetched scenario.

Option 7 is even more far-fetched. Stealing a certificate would require that the developer/company be reckless with the private signing key. In order to steal a cert, the attacker would need to A) get physical access to the key and B) crack the pass phrase on the key. A tall order. And, as the author admits, there have been no known cases of this ever happening. Again, a far-fetched scenario by his own admission.

Option 8 requires the same prerequisites as option 7: that is, an attacker would have to crack a developer's system, find the private key and then crack the pass phrase on the private key.

Conclusion: this PDF was written by an AV company which should automatically call its motives into question. In this case, it is clear to see that the PDF is intended to be nothing but FUD. It is nothing but a way to cause doubt as to the efficacy of digital signatures. The bottom line is if digital signatures are used properly and the keys properly managed, there is absolutely nothing to worry about. The AV industry wants the consumer to rely on THEM for all security needs and thus this campaign against digital certs.