[HN Gopher] Beware of Applications Misusing Root Stores
___________________________________________________________________
Beware of Applications Misusing Root Stores
Author : bzbarsky
Score : 58 points
Date : 2021-05-10 20:42 UTC (2 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| kodah wrote:
| 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 wrote:
| 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 wrote:
| Ah, got it. Thanks!
| commandlinefan wrote:
| 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 wrote:
| 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 wrote:
| "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
| FateOfNations wrote:
| 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).
| emmab wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ROARosen wrote:
| > 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 wrote:
| 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.
| ROARosen wrote:
| Are you saying that most apps don't rely on the system
| Trust Store?
|
| I believe manually trusting Fiddler's cert adds it to the
| Trust Store.
|
| The only iOS apps I couldn't successfully MITM with this
| were stock Apple apps.
| Operyl wrote:
| This isn't Apple or Google's fault that application
| developers are choosing to pin their certificates in their
| apps?
| sleevi wrote:
| Example app: NuGet for .NET on Linux and MacOS, from Microsoft:
| https://github.com/NuGet/Announcements/issues/56
|
| It used SSL/TLS and S/MIME roots to verify code signing and
| timestamping responses. When Symantec, which was removed for
| TLS trust, was also removed for S/MIME, NuGet broke, because it
| was no longer able to verify the TSA signature.
|
| As covered in https://github.com/NuGet/Home/issues/10504 , this
| then led some Linux distros, notably Debian/Ubuntu, to re-add
| Symantec.
|
| Any application using the ca-certificates package thus end up
| trusting CAs that Mozilla does not trust, despite being derived
| from the Mozilla Root Store.
|
| So the news is already out there, this was just a reminder to
| folks to _not_ do silly things like Microsoft did.
___________________________________________________________________
(page generated 2021-05-10 23:00 UTC)