6 ms·

Beware of Applications Misusing Root Stores

83 points by bzbarsky 5y ago

emmab 5y ago
> Additionally, some application developers directly parse a file in Mozilla’s source code management system called certdata.txt, in which Mozilla’s root store is maintained in a form that is convenient for NSS to build from. The problem with the scripts that directly parse this file is that some of the certificates in this file are not trusted but rather explicitly distrusted Could the file be split to retroactively fix everyone doing this?
- cipherboy 5y ago
  Sure, but some distros (read: Fedora that I know of) use this as a source of truth for their TLS Root trusts. Means the scope is larger than just Mozilla and they'd (hopefully) coordinate with downstreams and others prior to changing this. Best would be if they shipped a reference parsing library for whatever format they do use is. :-)
jeroenhd 5y ago
This sounds like a serious issue, and I wouldn't be surprised if news will come out soon about an app that allows for a massive security breach because it didn't use the root store correctly. S/MIME and HTTPS are quite different types of services, the former still usually relying on long-lived certificates whilst the latter is moving to shorter and shorter certificate validity, lessening the impact of a breach. Using S/MIME certificates to validate TLS might even allow a website to use the certificate of some random email address in your company to do a man-in-the-middle attack on your certificate, if the app's implementation was written badly enough. -- Offtopic: speaking of root stores and Mozilla, I'm still miffed about Firefox's decisions about the subject on Android. They removed the old root certificate management/installation pages, put a switch to enable the system's user certificate store in about:config and then removed the ability to use about:config from the stable release of Firefox for Android. I've seen a commit message saying that they moved the setting to allow the certificates the user explicitly installed on their system to work inside Firefox into a secret developer menu. I found that thread because I was looking into why my phone would randomly reset the about:config setting every day (because of a bug? because of the change? who even knows). My intranet websites work on pretty much every browser other than Firefox on my phone. It's really annoying.
- dheera 5y ago
  Also, I'm miffed about how hard it is to mitmproxy apps on iOS to see what they are sending to servers. I find this a massive privacy violation on Apple's part, and one of the main reasons I don't use an iPhone as my main device. I want to be able to see what apps are sending about me to their backend APIs. As usual, Apple fanboys, downvote away.
  - Operyl 5y ago
    This isn’t Apple or Google’s fault that application developers are choosing to pin their certificates in their apps?
    - aftbit 5y ago
      Well they could prohibit it if they wanted. They could even require that apps provide a method to inspect traffic. They never will though, because cert pinning is good for security, and any user-accessible method to access secrets becomes a target for phishing or other social engineering.
      - Operyl 5y ago
        That would certainly be the day I go "what the heck, Apple/Google." They could certainly try and prohibit it, but I don't think the backlash would bode well for them, and we'd only see people obfuscating their traffic even more.
  - ROARosen 5y ago
    > Also, I'm miffed about how hard it is to mitmproxy apps on iOS to see what they are sending to servers. Did you ever try with Fiddler? You can allow local connections through your PC and proxy through, download a Fiddler root cert, and it should work.
    - jrockway 5y ago
      I think the underlying problem is that the apps stop talking because the certificate validity check fails when traffic is proxied through your MITM. No MITM proxy can make that succeed, but if you can control the CA store that apps read, then you can create a certificate, add it to the trusted roots, use that cert to sign a certificate for someone else's website, and then when the app uses the system library to verify the validity of the certificate, it will appear valid, even though it's not. Without being able to hack the certificate verification, you can't MITM traffic between two devices you own. I think that's the complaint the grandparent has. Apps can still pin certificates, of course. At that point, you have to exploit the app's other faulty assumptions like "I'm running the same code that the compiler produced" or "writing 0 to memory address 0x12344321 and then reading memory address 0x12344321 will result in reading 0", which are straightforward to make false. Though probably not on a stock iPhone.
commandlinefan 5y ago
I feel like I'm missing some context here - they say applications are using the Mozilla root store "for purposes other than what Mozilla’s root store is curated for", but they never actually say what those purposes are. I wonder if they don't think it matters or if they're being deliberately secretive because there's an unpatched exploit floating around somewhere? That said, I can't come up with what somebody could be using a root store for besides validating a certificate.
- cipherboy 5y ago
  From the article, one use case they explicitly call out is code signing verification. Parties like Apple use x509/PKI certificates for code signing. A third-party application COULD use this trust DB for code signing verification. If an application is signed with a (root) cert trusted by this DB, it is allowed. Mozilla is saying woah: we only validate CA's TLS Server and S/MIME requirements (for CAs in our root DB). They don't validate that an arbitrary CA in their root DB has proper code signing certificate issuance procedures. So this theoretically application is in the wrong and they consider it a high severity vulnerability. But I agree, there's an open question about _who_ is using the DB this way.
- agwa 5y ago
  "Purpose" refers to the type of certificate, e.g. SSL/TLS certificate, S/MIME certificate, code signing certificate. Some roots in Mozilla's store are trusted for TLS only, some for S/MIME only, and some for both. The blog post is about applications which are using Mozilla's root store to verify certificates which are for a different purpose than the root is trusted for. For example, NuGet uses Mozilla's root store to verify code signing certificates, which is obviously wrong because none of the roots in Mozilla's store are trusted for the purpose of code signing: https://github.com/NuGet/Announcements/issues/56 https://github.com/NuGet/Announcements/issues/56
- FateOfNations 5y ago
  There likely is an unpatched exploit that Mozilla is aware of but isn't disclosing (to the public). I'd hazard a guess it's more related to blindly parsing the root store and trusting the certs that Mozilla has in there specifically for the purpose of not trusting them (DigiNotar, et. al).
kodah 5y ago
I think I'm missing some understanding. Does this include companies like Netskope that inject themselves into a systems root trust chain to MITM TLS communication?
- ectopod 5y ago
  No, I don't think it's about apps modifying the root store used by Firefox. Rather, it's about well-intentioned apps using Mozilla's root store in their own https client, but doing it incorrectly so they don't get the security guarantees they think they are getting.
  - kodah 5y ago
    Ah, got it. Thanks!
GauntletWizard 5y ago
Cryptosystems are hard. I've been thinking a lot lately about cryptosystems, and my thinking is that there's entirely too much complexity in this space: What works is keeping things simple. RE: CA Lists: Your CA list should be as short as it can be. The public CA list should be the public CA list, and you should use Mozilla's HTTPS list or Google's Chrome Root Store... but these lists are public lists for public infrastructure, and what you should use for communicating with services you don't control. Every company should have a CA. Possibly every division of every company. Don't throw them all in the same file. You should, as a client, make use of TLS Contexts: You should specify for every HTTPS Client a specific CA, which for internal services should be your own CA. As a server, client certificate auth is pretty rare (but it shouldn't be). When you do have it, you don't always have control over the client's root CA, but you shouldn't blindly trust it, either. You must verify that the claims on the client certificate match the claims on the CA, but also that the claims on the CA match your actual trust of the CA. The latter shouldn't be done at runtime, but during configuration. You shouldn't accept blind root signing certificates; You should accept from your clients intermediate CAs with appropriate constraints baked in. This brings into the equation another important problem: You shouldn't have complex claims on client certificates. I'm watching closely the SPIFFE project [1], which I believe is well intentioned but don't believe has got it right. I've also got my own project, KubeTLS[2] which implements a simple claims system - Which is appropriate in very limited constraints, but I believe those constraints also match most businesses real-world needs. [1] https://spiffe.io/ https://spiffe.io/ [2] https://gitlab.com/gauntletwizard_net/kubetls https://gitlab.com/gauntletwizard_net/kubetls

83 points by bzbarsky 5y ago

> Additionally, some application developers directly parse a file in Mozilla’s source code management system called certdata.txt, in which Mozilla’s root store is maintained in a form that is convenient for NSS to build from. The problem with the scripts that directly parse this file is that some of the certificates in this file are not trusted but rather explicitly distrusted Could the file be split to retroactively fix everyone doing this?

cipherboy 5y ago
Sure, but some distros (read: Fedora that I know of) use this as a source of truth for their TLS Root trusts. Means the scope is larger than just Mozilla and they'd (hopefully) coordinate with downstreams and others prior to changing this. Best would be if they shipped a reference parsing library for whatever format they do use is. :-)

jeroenhd 5y ago

This sounds like a serious issue, and I wouldn't be surprised if news will come out soon about an app that allows for a massive security breach because it didn't use the root store correctly. S/MIME and HTTPS are quite different types of services, the former still usually relying on long-lived certificates whilst the latter is moving to shorter and shorter certificate validity, lessening the impact of a breach. Using S/MIME certificates to validate TLS might even allow a website to use the certificate of some random email address in your company to do a man-in-the-middle attack on your certificate, if the app's implementation was written badly enough. -- Offtopic: speaking of root stores and Mozilla, I'm still miffed about Firefox's decisions about the subject on Android. They removed the old root certificate management/installation pages, put a switch to enable the system's user certificate store in about:config and then removed the ability to use about:config from the stable release of Firefox for Android. I've seen a commit message saying that they moved the setting to allow the certificates the user explicitly installed on their system to work inside Firefox into a secret developer menu. I found that thread because I was looking into why my phone would randomly reset the about:config setting every day (because of a bug? because of the change? who even knows). My intranet websites work on pretty much every browser other than Firefox on my phone. It's really annoying.

dheera 5y ago
Also, I'm miffed about how hard it is to mitmproxy apps on iOS to see what they are sending to servers. I find this a massive privacy violation on Apple's part, and one of the main reasons I don't use an iPhone as my main device. I want to be able to see what apps are sending about me to their backend APIs. As usual, Apple fanboys, downvote away.
- Operyl 5y ago
  This isn’t Apple or Google’s fault that application developers are choosing to pin their certificates in their apps?
  - aftbit 5y ago
    Well they could prohibit it if they wanted. They could even require that apps provide a method to inspect traffic. They never will though, because cert pinning is good for security, and any user-accessible method to access secrets becomes a target for phishing or other social engineering.
    - Operyl 5y ago
      That would certainly be the day I go "what the heck, Apple/Google." They could certainly try and prohibit it, but I don't think the backlash would bode well for them, and we'd only see people obfuscating their traffic even more.
- ROARosen 5y ago
  > Also, I'm miffed about how hard it is to mitmproxy apps on iOS to see what they are sending to servers. Did you ever try with Fiddler? You can allow local connections through your PC and proxy through, download a Fiddler root cert, and it should work.
  - jrockway 5y ago
    I think the underlying problem is that the apps stop talking because the certificate validity check fails when traffic is proxied through your MITM. No MITM proxy can make that succeed, but if you can control the CA store that apps read, then you can create a certificate, add it to the trusted roots, use that cert to sign a certificate for someone else's website, and then when the app uses the system library to verify the validity of the certificate, it will appear valid, even though it's not. Without being able to hack the certificate verification, you can't MITM traffic between two devices you own. I think that's the complaint the grandparent has. Apps can still pin certificates, of course. At that point, you have to exploit the app's other faulty assumptions like "I'm running the same code that the compiler produced" or "writing 0 to memory address 0x12344321 and then reading memory address 0x12344321 will result in reading 0", which are straightforward to make false. Though probably not on a stock iPhone.

commandlinefan 5y ago

I feel like I'm missing some context here - they say applications are using the Mozilla root store "for purposes other than what Mozilla’s root store is curated for", but they never actually say what those purposes are. I wonder if they don't think it matters or if they're being deliberately secretive because there's an unpatched exploit floating around somewhere? That said, I can't come up with what somebody could be using a root store for besides validating a certificate.

cipherboy 5y ago
From the article, one use case they explicitly call out is code signing verification. Parties like Apple use x509/PKI certificates for code signing. A third-party application COULD use this trust DB for code signing verification. If an application is signed with a (root) cert trusted by this DB, it is allowed. Mozilla is saying woah: we only validate CA's TLS Server and S/MIME requirements (for CAs in our root DB). They don't validate that an arbitrary CA in their root DB has proper code signing certificate issuance procedures. So this theoretically application is in the wrong and they consider it a high severity vulnerability. But I agree, there's an open question about _who_ is using the DB this way.
agwa 5y ago
"Purpose" refers to the type of certificate, e.g. SSL/TLS certificate, S/MIME certificate, code signing certificate. Some roots in Mozilla's store are trusted for TLS only, some for S/MIME only, and some for both. The blog post is about applications which are using Mozilla's root store to verify certificates which are for a different purpose than the root is trusted for. For example, NuGet uses Mozilla's root store to verify code signing certificates, which is obviously wrong because none of the roots in Mozilla's store are trusted for the purpose of code signing: https://github.com/NuGet/Announcements/issues/56 https://github.com/NuGet/Announcements/issues/56
FateOfNations 5y ago
There likely is an unpatched exploit that Mozilla is aware of but isn't disclosing (to the public). I'd hazard a guess it's more related to blindly parsing the root store and trusting the certs that Mozilla has in there specifically for the purpose of not trusting them (DigiNotar, et. al).

kodah 5y ago

I think I'm missing some understanding. Does this include companies like Netskope that inject themselves into a systems root trust chain to MITM TLS communication?

ectopod 5y ago
No, I don't think it's about apps modifying the root store used by Firefox. Rather, it's about well-intentioned apps using Mozilla's root store in their own https client, but doing it incorrectly so they don't get the security guarantees they think they are getting.
- kodah 5y ago
  Ah, got it. Thanks!

GauntletWizard 5y ago

Cryptosystems are hard. I've been thinking a lot lately about cryptosystems, and my thinking is that there's entirely too much complexity in this space: What works is keeping things simple. RE: CA Lists: Your CA list should be as short as it can be. The public CA list should be the public CA list, and you should use Mozilla's HTTPS list or Google's Chrome Root Store... but these lists are public lists for public infrastructure, and what you should use for communicating with services you don't control. Every company should have a CA. Possibly every division of every company. Don't throw them all in the same file. You should, as a client, make use of TLS Contexts: You should specify for every HTTPS Client a specific CA, which for internal services should be your own CA. As a server, client certificate auth is pretty rare (but it shouldn't be). When you do have it, you don't always have control over the client's root CA, but you shouldn't blindly trust it, either. You must verify that the claims on the client certificate match the claims on the CA, but also that the claims on the CA match your actual trust of the CA. The latter shouldn't be done at runtime, but during configuration. You shouldn't accept blind root signing certificates; You should accept from your clients intermediate CAs with appropriate constraints baked in. This brings into the equation another important problem: You shouldn't have complex claims on client certificates. I'm watching closely the SPIFFE project [1], which I believe is well intentioned but don't believe has got it right. I've also got my own project, KubeTLS[2] which implements a simple claims system - Which is appropriate in very limited constraints, but I believe those constraints also match most businesses real-world needs. [1] https://spiffe.io/ https://spiffe.io/ [2] https://gitlab.com/gauntletwizard_net/kubetls https://gitlab.com/gauntletwizard_net/kubetls