About the compromised eMudhra intermediate CAs
56 points by freddyb
56 points by freddyb
I find this entire situation kind of baffling: Apple successfully revoked trust in the compromised intermediates and also in the root CA that issued them via Security.framework (or wherever their root program actually gets stored), but they’ve failed to do the same for the CA bundle that much of their non-graphical userspace uses. Instead users are just left to run shell commands to patch it manually, which I assume the majority won’t (if they even become aware of this support page).
What is doubly baffling is that homebrew curl does verify through SecTrust. It’s the version that Apple itself distributes which doesn’t.
(I’m one of Homebrew’s maintainers.)
I think Homebrew’s curl actually uses Homebrew’s own CA bundle by default. It can use the SecTrust APIs but those aren’t the default because they’re deprecated by macOS and don’t support TLS 1.3. I think the same is true with the built-in curl, so it boils down to Apple just not shipping their own CA bundle update for whatever reason.
Yes, I was just thinking how bizarre it is to have an article that acknowledges the issue and then encourages manually editing the cert file instead of shipping an update to users!
Hm, I saw this on Daniel Stenberg's mastodon and presumed the claim was correct. I don't have any insight here beyond that.
Can you link to where it says that they're deprecated? (I don't think they should need to support TLS 1.3... they're just for validating the certificates you get from the handshake, right?)
I think you could use the SecTrust APIs for path building only but that isn’t how curl uses them currently, I believe it uses them for the entire TLS stack. The curl maintainers probably have more context on that decision and why it makes sense for them.
I think SecTrust is not deprecated and can be used without SecureTransport. I should dig in and see if I can offer curl a patch that does that for other TLS APIs. I think that'd be useful and would avoid this specific problem.
How would SecTrust support TLS 1.3? Isn't it solely about certificate verification?
I was using it as a shorthand for Secure Transport, which is the deprecated TLS stack on macOS (including X.509 path building).
My best guess is that they cannot change that CA bundle without releasing a whole OS update.
That was what I thought too, but macOS has had “rapid security release” functionality for the last few years. In principle they should be able to ship this via an RSR, which doesn’t even necessarily require a reboot.
Apple doesn’t provide guidelines for their their RSR process, but something this severe still doesn’t qualify. What that process is for is to push changes where users devices are actively being exploited in a destructive way.
The RSR process is a highly risky action, where the potential cure make be worse than the sickness.
Aside from some early RSR tests (which almost certainly received extensive testing), there haven’t been any in years.
Think of it this way: in the wild zero day RCE kernel mode exploit that affects all iOS devices.
I mean, this is a complete break in the Web PKI. It’s tantamount to RCE for development flows, of which a significant percentage of Apple customers perform daily/constantly. And the roots in question have been safely removed by Apple everywhere else, just not in this specific bundle.
I don’t have an opinion about whether Apple should do it as an RSR or not, but it absolutely qualifies as something that needs to have been fixed yesterday.
Can that be used to push any arbitrary change?
I don’t think so, I think it’s limited in size and complexity. For example I don’t think it can be used to deploy most kernel changes, although I might be wrong about that. Modifying the CA bundle is the kind of thing that should be within its capability, though.
I think the fact that that bundle is in a spot protected by System Integrity Protection means it would require a system reboot. And I thought that was the line for the rapid release patches, but I'm not certain of that.
I just checked and this CA bundle actually isn’t protected by SIP. You can modify it with a normal elevated shell and it takes effect immediately.
(I agree that it would be another story if it was SIP’d!)
Thanks for checking that. I'm kind of shocked that it's not SIP'd. Absent that, I'm surprised they didn't use their RSR feature!
The funny thing is that while you can edit it, that change will also be overwritten by the next OS update, at least according to the OP page.
Wait Apple STILL hasn't blocked the certs other than in some GUI apps??
Xcode Command Line Tools — like curl and git — check certificates against /etc/ssl/cert.pem and can still accept these certificates until a future software update.
Why the hell hasn't that "future software update" already shipped?
Do I need to edit /etc/ssl/cert.pem?
What? This is written as if there aren't millions of developers (and their agents) out there using command line tools on a Mac every single day.
It's written as if developers aren't the only people who may find themselves reading this article that doesn't have "for developers" in the title.
I had macOS on my work laptop for a few years, and I gotta say, as a developer, the experience left me feeling like a second-class citizen. Compared to pre-WSL Windows, though, at least I was a citizen!
Really weird that removing the AAA root is labeled "optional" since if you don't remove it, then doing the other steps is pretty much pointless
WRT the cert bundle stuff: Makes me think deprecating Secure Transport might have been a mistake if their LibreSSL build won't support the system certificate store and modifying non-Apple world things to support Networking.framework is highly invasive (as curl figured out).
WRT the cert bundle stuff: Makes me think deprecating Secure Transport might have been a mistake if their LibreSSL build won't support the system certificate store and modifying non-Apple world things to support Networking.framework is highly invasive (as curl figured out).
Go has its own TLS stack but it uses the “platform verifier” on macOS. I wonder how they do it.
edit: https://github.com/golang/go/blob/master/src/crypto/x509/internal/macos/security.go