Comment by invokestatic
4 hours ago
Going against the grain here but I think this is decent security engineering from Apple. They patched the highest exploitable things immediately (Safari, Mail, etc). The residual risk is using these command line tools while someone is actively MITMing your connection.
How often are people “git clone”ing a repo without browsing to the GitHub site first? Safari would throw up certificate errors. And also, TLS on Git doesn’t even authenticate the code you’re downloading is legitimate at all. It could be modified by the Git host or a supply chain attack, etc.
Yea, it’s not great. Ideally the risk is reduced to zero from patching. But a lot of the times we accept some level of cybersecurity risk out of practicality. This is why we have responsible disclosure windows lasting months. It takes a while to do proper release engineering and testing for something like a whole OS update.
I really don't understand your justification.
One of the certificates literally has a private key of 4; it's as compromised as it could quite possibly be. This is not a "one of the intermediates have a weak and possibly crackable key" or "a bunch of incorrect certs were issued but the issuance was patched".
To a MITM attacker, git clones can be easily distinguished from visiting in Safari. You could choose to only poison git clones; without poisoning anything else.
Heck, you can probably build an exploit kit in a hour; camp out around a Starbucks or McDonalds with open wifi, and start compromising git clones and deliver malicious payloads.
An attacker absolutely cannot “easily distinguish” between a git clone and visiting the website and swap the certificate.
To know whether a request is a git client or web browser, an attacker needs to be able to inspect the contents of the web request (to check the user agent or whatever). If the site is using a legitimate certificate, the attacker has no way to inspect the contents because it is encrypted with a key they do not control.
If an attacker used their own, eMudhra-signed certificate, it would throw the certificate error in Safari.
Yes, I'm assuming network MITM and DPI.
The whole point of TLS and certificates is to counter network MITM attacks.
Browsers and clients emit a lot of fingerprints, you can probably figure it out loosely from the TLS initialisation.
2 replies →
Some questions from a netsec novice:
1) Why wouldn't you have a SSOT for certs and instead rely on patching different apps individually?
2) Doesn't this violate defense in depth? Exploits for a widely disclosed issue now have turnaround activation within hours, not weeks. Not patching all surface areas and actively disclosing as such seems very much like drawing up a map for a jailbroken LLM to gin up a rudimentary attack.
3) Also doesn't this violate the principle of secure by default especially for power users who are more likely to be the ones with higher privileges across distributed systems?
Historically, stuff like openssl and cli command tools used flat files like /etc/ssl/certs.pem.
Browsers came along and they wanted to maintain their own cert store because operating system flat files were often out of date.
Operating systems grew their own stores because they wanted some kind of registry that was more integrated with the rest of their ecosystem.
Nobody coordinated. CLI tools and unix libraries don't care about browsers or O/S registries, operating systems have requirements so that they can't use the flat files, everyone screams about stuff like systemd turning unix into windows.
And it will continue to proliferate. System management tools often ship their own certs since the O/S certs can be out of date and untrustworthy and may not be able to talk to AWS before you bootstrap the management tool and update the system certs because people still run ancient shit like RHEL5. This is more or less the same reason browsers ship their own as well. I've made the decision to ship an embedded cert store in a product before, and nothing has fundamentally changed that would cause me to rethink that decision (even though for people who have an up-to-date O/S it is strictly additional cost that they now have to track a cert store in another product--but you have to build for the lowest common denominator).
1) I would argue that different trust stores are a carryover macOS’s Unix heritage. Having multiple roots of trust is actually very common. For instance Firefox maintains their own root of trust from the system, it’s called NSS. Different programming languages like Java and Rust also often use different roots. It’s not amazing, and has holes, but a lot of it comes down to historical reasons and a certain level of risk acceptance.
2) Yes, but actually, this is exactly why we have defense in depth. This is a temporary measure while a permanent patch is coming. Defense in depth means a single hole does not result in compromise. I would argue that this situation with Apple demonstrates defense in depth actually working as intended. If this was the permanent solution, and no further patch was coming from Apple, then yes, it would violate defense in depth.
3) Related to above, yes. But it’s not permanent.
> How often are people “git clone”ing a repo without browsing to the GitHub site first?
People are going to be running pull or push much more than clone, and will often be running those without opening the origin on Safari.