Apple's git still trusts compromised eMudhra certificates, and macOS 27.2 made it worse
Ten days later, Git on macOS still trusts the compromised eMudhra certificates
Apple was notified of the eMudhra certificate compromise on October 17, but git, curl, and python3 shipped with macOS still trust the affected roots as of October 28. macOS 27.2, released October 26, didn't fix it and even reverted users' manual workarounds. Anyone on the network path can intercept HTTPS clones, pushes, and GitHub tokens. Dozens of volunteer-run projects patched days ago; Safari is already protected.
Worse, macOS 27.2, released on 26th October, did not fix the issue and undid the workaround that users had applied by hand, leaving them vulnerable again.
- chrisweekly
Right, so it's not just git, it's a bunch of system-provided utilities; macOS trusts bad certs, and these utils that trust the OS are affected. I use homebrew for my git and curl but haven't yet checked to confirm whether that matters here.
Kind of outrageous that Apple's guidance is to edit the cert chain manually, and to expect that subsequent OS updates may revert your mitigation, reintroducing the vulnerability (as happened at least once so far).
- jrochkind1
That MacOS hasn't removed from OS-level /etc/ssl seems like a big deal, affecting more than just OS-supplied git. Is /etc/certs not used by most graphical Mac software, I guess? The chaotic state of OS-level cert management, on Linux as well, is pretty dismaying.
If Apple is still trying to brand themselves as security-forward, you'd think removing the revoked CA certs from /etc in a system update would be a pretty easy thing to do?
- truelson
Here's what apple (themselves) recommends to patch: https://support.apple.com/en-us/149555
Pretty much every developer on mac should probably run their patch.
- qaz_plm
Apple’s statement: https://support.apple.com/en-us/149555
- faxmeyourcode
While there is no proof that anyone knew about these weak keys for the year and a half that they were trusted by virtually everybody, and there's no evidence of MITM attacks happening in the wild because of it, you can imagine the payoff that a three letter agency would have if, for even 10 days, there was an opportunity to harvest credentials from important people in high places.
I have no evidence or proof, but I am convinced this wrap/unwrap key generation debacle was intentional and the weak keys were discovered and kept secret by the agencies or governments and used to exploit their adversaries.
You don't need to perform a traditional MITM attack _if you own the airport_ or you _own the free public wifi_. The traffic can be harvested in clear text and we have to come to terms with the _remote possibility_ that this was going on for over a year and a half. If not that long, then certainly for the past 10 days.
- kryptiskt
I'm not being sarcastic when I say that Apple should copy Windows Update, I have no idea how they have got this far without a method to add small patches outside monolithic OS updates.
- commandlinefan
It seems like we've all just... given up on certificate revocation? CRLs and OCSP were designed for exactly this sort of thing, but they both seen to have been abandoned as unworkable with no replacement.
- gringofyx
A flat cert.pem file (or similar) can't say "distrust this intermediate".
macOS already has the verifier needed (Security.framework/trustd path that protected Safari). It would be good if MacOS routed CLIs through it.
- kd913
They just released MacOS 27.2 a few days ago? How and why did they not do a patch at least then?
- mFixman
Question for people who know about this: why do we have hundreds of root certificate authorities, when a vulnerability on a single one can break encryption?
Wouldn't it make more sense to have 5 or so that can be more closely monitored, so something like the eMudhra certificates would probably be found before the certificates are deployed?