What a clusterfuck
[–] dist-epoch 1 day ago
[–] LoganDark 1 day ago
Also, if they truly didn't care about Terminal users, they would not have even published this article!!
[–] dns_snek 1 day ago
Most notably agents like Claude Code and Codex? Easy to check if you ask it to run:
$ curl 'https://dv-g3b-emudhra.we-have-a-problem.com/'
Your client successfully connected to the site. That's bad![–] zahlman 1 day ago
[–] Polizeiposaune 1 day ago
See the lists in https://bugzilla.mozilla.org/show_bug.cgi?id=2083449; I believe that "dv-g3b-" corresponds to the intermediate CA certificate listed as "EM DV TLS CA - G3B"
DV/OV/EV are "Domain Validated", "Organization Validated" and "Extended Validation" which refer to different levels of checking that the CA should done before issuing a certificate with a particular name in it.
[–] dspillett 1 day ago
A lot do it because sometimes there is no convenient library wrapping what they are trying to check or execute that they are aware of, and running a cli command is generally cheap unless you are doing it in a tight loop. A lot of the time this is “it'll do until I find the right library or bindings” code that should have been fixed before release, but it isn't all as bad as running top as you describe.
[–] curt15 1 day ago
[–] Wowfunhappy 1 day ago
I agree, you're on a *nix OS, calling a CLI tool should be a perfectly valid way to do something.
IMO the real issue is that Apple's built-in CLI tools aren't properly integrated with the rest of the system. Apple's curl used to use the same certificate store as the rest of the OS, then Apple changed it.
[–] krackers 1 day ago
It was technically curl that dropped SecureTransport but I guess because no one at Apple was willing to maintain it and it apparently is a frozen API that doesn't support newer than TLS 1.2 (!). For a while their inbuilt curl could use both but preferred LibreSSL anyway.
https://daniel.haxx.se/blog/2025/01/14/secure-transport-supp...
[–] Wowfunhappy 16 hours ago
Well yeah, so not really curl's fault here.
More importantly, IIRC Apple's curl actually stopped using SecureTransport before upstream dropped it.
[–] 1-more 1 day ago
Huh, I tried to do this a long time ago and permissions bit me and I quit. I was making a nice UI that would run ffmpeg to stitch together some video files, so it would use native UI elements to pick the input files and output location, then generate the ffmpeg command and run it. It worked fine on my machine but it ran into permissions on my friend's machine who needed it and I gave up because they found something better.
[–] saidnooneever 23 hours ago
ofc it does matter what they do in there, but would users really need to figure all that out themselves and strace all the things to see whats going on down there? :')
truly poor response. happy i dont use apple.
such an expensive flytrap
[–] dist-epoch 1 day ago
[–] invokestatic 1 day ago
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.
[–] dannyw 1 day ago
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.
[–] invokestatic 1 day ago
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.
[–] dannyw 1 day ago
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.
[–] invokestatic 1 day ago
1) An attacker is MITMing your connection. This is already not easily exploitable by most threat actors short of being on a public Wi-Fi network, otherwise you are likely at the nation-state level attacker at this point.
2) An attacker knows exactly which Git repo you’re about to clone and has prepared a malicious version (noting they can’t snoop on your encrypted web traffic).
3) An attacker has developed a way to differentiate between Git over HTTPS and Safari, by using a side channel “fingerprinting” method that works with your exact versions of git and macOS.
4) You don’t pin the git clone to a particular hash or signature.
This is already a very low level of exploitability. All of these things need to be satisfied for the attack you’re describing to work.
Now let’s look at a more practical attack that exists regardless of if you have the patch from Apple.
1) A maintainer of an open source project you use has their GitHub account compromised due to credential stuffing and commits a malicious version.
2) You don’t pin the git clone to a particular hash or signature.
This attack is significantly more exploitable and has happened over and over again in supply chain attacks.
But look at the commonality: in both, no certificate pinning or signature checking was done. If you follow best practices, this stops both attacks dead cold.
This is the security engineering. It’s not just checking boxes. It’s evaluating risks.
[–] dpark 1 day ago
This is absolutely not security engineering. This is nit picking a specific attack factor and trying to argue that it’s impractical. I suspect you are wrong, but it doesn’t matter, because you are ignoring the broader class of attacks and focusing on one specific example. The class issue is that on a Mac, you cannot trust any terminal-based application to honor the CRL. This means that any site accessed from a terminal based application cannot be trusted. There are a billion ways to exploit that.
This is not good security engineering from Apple. There is no way to justify this. Humans make mistakes, and that’s just life, but we shouldn’t pretend that this is an acceptable state or an acceptable response.
[–] paimapi 1 day ago
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?
[–] dualvariable 1 day ago
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).
[–] invokestatic 1 day ago
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.
they solved the issue for the people they care about