digital signatures are not a poor man's whitelist

back when mcafee had their catastrophic false positive i made the suggestion that av vendors in general (and mcafee in particular) could use a whitelist of critical system files to avoid false alarms that render systems unbootable/unusable. basically the idea being that known trusted files could be ignored by anti-malware components prone to false alarm. in the comments of that post didier stevens suggested checking digital signatures of files could be used as an alternative. at first i thought that was an OK compromise to developing a proper whitelist of critical files, but recent events have made me rethink that.

as kaspersky's alexander gostev described, a digital signature will cause a file to be regarded as trusted by security software, much like didier suggested in his comment, and if it's malware that means it will be effectively hidden from the anti-malware software.


i think that's a pretty glaring problem and underscores the fact that digital signatures are a poor substitute for a proper whitelist. a proper whitelist is constructed of items that are known and trusted, but with digital signatures it's neither the anti-malware vendor nor the user who's constructing this implied whitelist. instead, the implicit whitelist is constructed jointly by every tom, dick, and harry who happens by hook or by crook to get his/her hands on a valid digital certificate. that means the people who make the determination of whether a file is safe and/or trustworthy are (generally) the same ones who created it. however, those people could lie, they could fail to actually check the safety/integrity of the file they're signing, or they might not even be qualified to check the safety/integrity of the file they're signing. even if the owner of the digital certificate used to sign the file is a trustworthy entity, that doesn't mean the file is also trustworthy. first and foremost, trust is not commutative. besides that, though, as the stuxnet example shows us, the certificate can fall into the wrong hands. treating digital signatures as whitelist entries creates a situation where altogether too many entities have influence over what is considered trusted and safe.

thus digital signatures can not tell us what we need a whitelist to tell us, namely that the file is trusted and safe. the presence of a valid digital signature only tells us two things: that the file was signed with certificate X (which may or may not be under the exclusive control of the party it was issued to), and that the file hasn't changed since it was signed. whether it's safe, whether it's fit for use, is entirely outside the scope of what a digital signature can tell us.

i think the idea of using a whitelist to avoid false alarms is a good one, but using digital signatures in it's place is a shortcut. av vendors need to stop cutting corners and implement proper whitelists for this particular application. there are already tens of thousands of digitally signed malware samples in f-secure's collection so i'm at a loss trying to figure out why this technique of false positive avoidance hasn't been abandoned already. now that news that detections of stuxnet didn't start until after the digital signature expired, malware authors will surely be looking to exploit this behaviour more and more.

virustotal usage FAIL

from rich mogull's post There Are No Trusted Sites: Paris Hilton Edition:

The best part? Only 12 of 37 tested AV vendors catch the trojan. All of who that give me crap for hammering on AV can go away now.

yes, boys and girls - in spite of my prior warning on the matter, in spite of didier stevens' thoughtful post on the matter, and in spite of hispasec's own post on the matter, people still don't get that virustotal is for testing suspected malware not anti-malware...

it doesn't matter if your sample size is 1 or 1000, using bad virustotal results to bolster the argument that av sucks (when it's well known that virustotal's results don't/won't match av user experience) is a big fat FAIL...

rich isn't the only one failing here, though, he's just the most recent example... 'incident handlers' at the internet storm center do this on a regular basis, as do quite a few others...

the devil's in the details folks, start paying attention... since the detective capabilities displayed in the context of virustotal do not represent the real detective capabilities of the products used by virustotal, what point can there really be to posting the detection rates (as dancho danchev likes to call them)? that's right, basically none - not only do they bear no relationship to what is conventionally thought of as detection rates, but also they are NOT accurate...

now repeat after me: virustotal is for testing suspected malware, not anti-malware...