Re: Firefox Add-ons
Eddy Nigg wrote: no CA was here admitted under these conditions for having the code signing bit turned on. I'm not saying that at some point in PKI history this wasn't done. It's not done today and fee free to publicly name the CA which does that. Last I checked there definitively were some code signing certificates basically issued under the terms of If the credit card check comes back OK, issue it. It's a little while ago thought. But really. It's *hard* to do better than that, better than Send us by fax our doctored ID so that we check if you pass the bar of having minimal photoshop skills. If and when people will have a governmentally issued cryptographic ID card, it will become a lot easier, but then the code signing CA will have little room for added value. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
Last I checked there definitively were some code signing certificates basically issued under the terms of If the credit card check comes back OK, issue it. It's a little while ago thought. But really. It's *hard* to do better than that, better than Send us by fax our doctored ID so that we check if you pass the bar of having minimal photoshop skills. No CA has been admitted to NSS during the last 2+ years based on such a policy and have the code signing bit turned on. Your assumption above is wrong, but if you have any knowledge please share it with us :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On Feb 6, 2010, at 10:43 AM, Eddy Nigg wrote: On 02/06/2010 08:30 PM, Lucas Adamski: I don't think it would have made a tremendous difference here. One of them was likely infected accidentally (only one version of the addon contained malware and the developer is actively communicating with us). In this case perhaps - in another case you perhaps will stay with the damage and never hear from the developer. The point is even a well legitimate intentioned developer with a code signing cert could ship malware by accident. Code signing doesn't prevent malicious code from being inserted into an addon. Yes, it makes it much harder for hobbyist developers to create addons but doesn't stop the bad guys from getting their hands on *some* code signing cert, either by stealing one or via a shell company in some foreign country. Errr...I hope not, otherwise what's the point of code signing certificates anyway. Its not hard for bad guys to get *a* code signing certificate. In a previous life I encountered malicious ActiveX controls that were signed with a valid chained cert. Never figured out if the cert was stolen or if the org was intentionally distributing malware. But that didn't really matter. Code signing is useful when the user is trying to authenticate that the code they have in hand was issued by a specific organization that they trust. If you aren't trying to make a trust decision based upon the publisher then code signing buys you very little. What it does create is a huge burden on developers that requires them in many countries to be incorporated or at least have a business license, and provide a stack of paper documents to that effect. So the bad guys can always steal a cert or buy one via a shell company in Russia, while many of the good guys can't buy one at all. Lucas. The real problem IMHO is that we allow unreviewed addons to be downloaded directly from AMO. Yes, but is it feasible to review every add-on? Maybe it's not such a burden - and what about modifications of existing add-ons? Are they reviewed too? It is a big burden, I wouldn't try to sugar coat it. However code signing doesn't relieve that burden in any way IMHO, they solve orthogonal problems. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/08/2010 09:28 PM, Lucas Adamski: In this case perhaps - in another case you perhaps will stay with the damage and never hear from the developer. The point is even a well legitimate intentioned developer with a code signing cert could ship malware by accident. Right - and I believe that this isn't the problem code signing is intended to solve. However it does protect from tempering as Steven pointed out in the other list. If you aren't trying to make a trust decision based upon the publisher then code signing buys you very little. What it does create is a huge burden on developers that requires them in many countries to be incorporated or at least have a business license, and provide a stack of paper documents to that effect. Today you can get code signing certificates as individuals too. Sometimes that's even better than some Ilse of Man limited liability company hold by one guy and setup through online registration. Yes, but is it feasible to review every add-on? Maybe it's not such a burden - and what about modifications of existing add-ons? Are they reviewed too? It is a big burden, I wouldn't try to sugar coat it. However code signing doesn't relieve that burden in any way IMHO, they solve orthogonal problems. You are right. But perhaps it might be of help to know that this developer is the same one as last time and he signed his code. Knowing that there is a real person (or organization) behind the code might be of help too. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
I think such a document could go a long way to help people understand how Mozilla protects them, the limitations that are faced, and what happens when something goes wrong. If they still feel like it isn't enough, then they can be prompted to suggest improvements to the process. Speaking of improving the process, I agree with Daniel Veditz that the experimental add-ons should be made available on another site. Even the term 'experimental' gives the impression (to me anyway) that the add-on is potential beta quality, not potential pwnage. Maybe 'unverified add-on' would be more appropriate. - Bil Sid Stamm wrote on 2/8/2010 3:56 PM: Hi Bil, I don't believe we have a document precisely along the lines of what you suggest (as far as I know) but we have these other documents that are sometimes helpful: https://developer.mozilla.org/en/Security_best_practices_in_extensions https://addons.mozilla.org/en-US/developers/docs/policies https://addons.mozilla.org/en-US/developers/docs/policies/reviews -Sid On 2/7/10 10:02 AM, Bil Corry wrote: Eddy Nigg wrote on 2/6/2010 7:04 AM: Isn't it about time that extensions and applications get signed with verified code signing certificates? Adblock Plus is doing for a while now I think, perhaps other should too? Because this isn't really comforting: http://www.theregister.co.uk/2010/02/05/malicious_firefox_extensions/ Not sure if it already exists, but it would be helpful if there was a document that describes the security practices of AMO; something that outlines the responsibilities of Mozilla, of the AMO developers, and the users, along with outlining the risks involved and what happens when they're realized (such as using the block mechanism). That way, when news such as the above is reported, this document can be referenced. Threats to address, that at least I'm aware of: (1) Malware in add-ons (see above article) (2) Trusted add-ons subverting each other http://hackademix.net/2009/05/04/dear-adblock-plus-and-noscript-users-dear-mozilla-community/ (3) Untrusted add-ons doing bad stuff. (4) Fake add-ons posing as a trusted add-on: http://www.webappsec.org/lists/websecurity/archive/2010-01/msg00128.html (5) Trusted add-ons that pose a security risk: http://blog.mozilla.com/security/2009/10/16/net-framework-assistant-blocked-to-disarm-security-vulnerability/ (6) Subverting the update mechanism (this is for FF, but might apply to add-on updates too?): http://ha.ckers.org/blog/20100204/releasesmozillaorg-ssl-and-update-fail/ (7) Subverting the blocklist mechanism (to disable, say, noscript): https://support.mozilla.com/en-US/kb/Add-ons+Blocklist I'm sure there are many many more. BTW, this presentation from OWASP DC names Eddy Nigg, Giorgio Maone, and developers at Mozilla (among others) as The 10 least-likely and most dangerous people on the Internet: http://www.owasp.org/images/1/1f/The_10_least-likely_and_most_dangerous_people_on_the_Internet_-_Robert_Hansen.pdf - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
