6 ms·
> I trust a developer who drops some $$$ on a code-signing certificate more than I trust a developer who doesn't. This is a misapplication of Bayes theorem.
by kbutler 8y ago
> I trust a developer who drops some $$$ on a code-signing certificate more than I trust a developer who doesn't.
This is a misapplication of Bayes theorem.
P(bad) is the probability any app is bad
P(signed) is the probability any app is signed
P(bad if signed) = P(signed if bad) * P(bad) / P(signed)
Essentially your trust model requires that "the fraction of bad apps that are signed is small", or P(signed if bad) approaches 0. But signed malware is available - famously stuxnet, but others before and since: http://users.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf http://users.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf
Malware authors have incentive to make their apps appear legitimate, either by stealing keys, impersonating companies, or other mechanisms. Signing also helps get past automated checks (per the paper above).
Further, those probabilities assume random distribution, but I'd suggest that really expensive/dangerous malware has greater incentives to appear safe, so it is even more likely to be signed, even if most malware is not. Stuxnet would be a case in point - high value, sophisticated malware, signed.
P(really bad if signed) = P(signed if really bad) * P(really bad) / P(signed)
P(really bad) is lower,
but P(signed if really bad) approaches 1,
so P(really bad if signed) approaches P(really bad)
Meaning the worse the malware, the less the signature tells you.
- marcosdumay 8y agoAll the GP is saying is that he believes that P(signed if bad) < P(signed). It's a fair belief because paying for something leaves a paper trail. MS certificates are a farce at $500/year, but Google's $20 once is a very reasonable thing. Your point that really bad malware has higher odds of being signed is a good one, but really bad malware is much less likely than simply "malware".
- kbutler 8y agoI believe he's saying P(bad if signed) < P(bad if not signed) - "I trust signed apps more than unsigned apps". I'm saying, maybe, but I'm not sure, and Cost * P(bad if signed) may be much worse than Cost * P(bad if not signed). When the Transmission bittorrent client site was hacked to distribute ransomware, it was signed using an unrelated certificate that was likely stolen. This happened twice within a year, with different valid (stolen) certificates: https://blog.malwarebytes.com/threat-analysis/2016/09/transmission-hijacked-again-to-spread-malware/ https://blog.malwarebytes.com/threat-analysis/2016/09/transm... Stuxnet certificates were also stolen. This disproves the GGP's premise that a signed app implies the developer paid for it, as well as your assumption that the paper trail for legally acquiring a certificate is an impediment to signing malware. You're not only trusting the developer who purchased the certificate and the CA that granted the certificate, but also trusting the ongoing security of everybody else who has purchased a trusted certificate. That's a pretty open circle of trust. Certificate revocation can limit the time of exposure once malware is distributed, but it isn't always implemented. https://arstechnica.com/information-technology/2017/11/evasive-code-signed-malware-flourished-before-stuxnet-and-still-does/ https://arstechnica.com/information-technology/2017/11/evasi... "they found 189 malware samples bearing valid digital signatures that were created using compromised certificates issued by recognized certificate authorities and used to sign legitimate software. In total, 109 of those abused certificates remain valid."