YHK - yet another hacker news clone

Uname is not enough here to identify what has or has not been done to your system to deal with the compromised certificates.

    $ uname -a
    Darwin MacBook 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:21 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T6030 arm64 arm Darwin
    $ which curl
    /usr/bin/curl
    $ curl https://dv-g3b-emudhra.we-have-a-problem.com/
    Your client successfully connected to the site. That's bad!

You could be running a different version of curl, e.g. homebrew. Try `which curl` and `/usr/bin/curl <url>`.

Is using the system CA not the way to go?

(on linux you always have the update-ca-certificates command that downloads the root certificates from a trusted™ source. but sure, it will not help, if each command starts to bring their own ca package :)

Agreed.

So git on MacOS does trust compromised certs by default? What's wrong with the title then?

The lede is certainly buried, but calling out an affected development toll on a tech site isn’t a bad call.

Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.

Indeed!

  On Mac, some command-line tools included with macOS or the Xcode Command Line Tools (including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem. For certificates that chain to a root CA certificate in this file, these tools don't check Apple's block or whether the certificate has been revoked. This file will be updated in a future macOS update. If you use these tools and don't want to wait for the update, you can remove root CA certificates from the file.

Are they just saying "do it yourself"? Can't they just send out an update?

Not sure what Linux offers that's any better. Didn't Debian ship trivially weak SSH keys for over 2 years because they were trying to silence Valgrind warnings and the random maintainer had no idea what they were doing and there was no oversight or peer review whatsoever?

It's funny. When Apple goes in and changes peoples systems deeply without consent then it's Apple being evil. When they don't, it's Apple being evil. Heads I win, tails you lose.

> You have to compromise a lot to be able to make a MITM here.

It's trivially easy to mount an ARP spoofing attack. I did that at school two decades ago and on-the-fly rewrote <img src=...> to hardcore porn images for funsies.

mitmproxy [1], a popular toolkit for making that easy, has the option to generate "eMudhra" certificates on the fly now.

It is trivially easy to compromise things, all you need is physical access to the network.

[1] https://news.ycombinator.com/item?id=50189232

It's pretty easy to compromise things like McDonalds or Starbucks WiFi hotspots though, just setup a Pineapple with the right SSIDs and a 5G modem, funnel your target domains through your mitmproxy via the DHCP DNS server you're providing, and that's basically it.

I agree it's not PHP2Shell, but its certainly not being "way overblown" here.

Don't underplay it either though: with a compromised but unrevoked signing cert all it takes is a successful phish, or some problem to allow DNS poisoning (or hack a wireless AP, or …) to direct you to a fake site or (potentially worse as it might be less immediately noticeable and could quietly collect credentials/data for a while) send your automated tools to a malicious API.

It may not be directly exploitable on its own, which is the impression some reports give, but it is a serious hole to leave open especially with the current rate of old security issues being found, as it could be _incredibly_ useful to a malicious actor as part of an exploit chain.

php2shell was overblown perhaps but this is being blown quite correctly

You can take your laptop to a busy place, make a "free wifi" hotspot that runs everything through mitmproxy and you can steal everything.

The near-universal use of TLS and the absurd ceremony we go through to ship root CAs everywhere is all premised on the idea that MITMs are not terribly difficult.

The entire reason one can rest easy as they connect to their coffee shop's WPA2-PSK network, is the security provided by TLS.

And if you don't think an ISP or agency would abuse this if it could be done undetectably then you haven't been paying attention these last 20 years (hence why DoH is now a thing).

If you hijack the DNS, the laptop can be pwned quite easily. Think of all the coffee shops with unprotected routers out there.

> You have to compromise a lot to be able to make a MITM here.

This is just an argument against TLS in general. Use plain http if you believe this.

This is way worse than PHP2Shell in scope of impact and its effects will stick around for much longer. Well, as long as the validity period of the compromised certs anyway

The TLS trust chain is the last defense against MITM attacks. The prevalence of MITM attacks is in fact the very reason TLS exists. I'd say it's a lot worse than PHP2Shell because it doesn't only affect poorly maintained servers, but potentially ALL credentials and secrets a user sends over a compromised network with compromised CAs on their device.

The window of opportunity to MITM has passed. If you attempted an MITM from an easy vantage such as telco, ISP, or public wifi you'd be trivially detected as a significant portion of devices are patched, including on these unpatched macs as only the *nix commands are affected and not app bundles.

It's actually worse: Installing the 27.2 update after manually cleaning out /etc/ssl/cert.pem will revert those changes and put the eMudhra CA back in.

Source: https://mstdn.social/@jschauma/117513596272504904 https://mastodon.social/@glyph/117509558825919922

Was thinking the same. My assumption would've been that this would have been a normal and routine enough of an operation to be able to push through without needing a separate RC process.

To be honest, git deferring to the OS is the right thing to do. It's macOS that's the problem, not git.

"Ten days later, macOS and all applications that rely on it still trust the compromised eMudhra certificates" would have been a better title.

Yeah they do, it's called "Background Security Improvements" but they rarely use it lol

yeah, it's a good habit to have. Unfortunately, GH defaults to the TLS transport.

I use SSH for things which are private or which I may want to push to, but I use HTTPS for everything I just need to download. SSH typically requires that you create an account with whatever the git host is and upload your public key.

SSH in typical use is not vulnerable to a compromised root certificate, instead it's "just" vulnerable to you having no idea whether you can trust that host key or not, so you just blindly say yes and hope for the best. At least if the key changes, you'll know something was wrong; maybe it was this connection that got compromised, maybe it was the first connection that got compromised, maybe the legitimate host just rotated their keys, who knows. SSH security against MITM is mostly based on lack of motivated attackers and wishful thinking.

That page is an insult to their customers. So what, if I want to be protected from a security issue you acknowledge, I'll need to make modifications to my system configuration?

It’s interesting they call out as “optional” removing sectigo roots.

If you’re not removing them you better be sure anything that runs on the system has full revocation support including intermediates. Which is.. kind of an impossible thing to assert as true. Which is why most trust stores just removed that as well last week.

Yeah, why may that be hard? That’s the question

I don’t think it’s gross incompetence, since they documented the steps to remove. They may have some unexpected dependency on the file? Looks mysterious from the outside.

> Is /etc/certs not used by most graphical Mac software, I guess?

Correct, those usually use Apple's networking APIs which all go through their security stack, which already picked up the OCSP revocation within about 2 hours in most cases.

this only affects terminal apps, which the vast majority of MacOS users don't run; the fix for graphical Mac software is already patched

my guess is their thinking is that if you're running those apps on Mac, you're a developer or know what you're doing, and can edit /etc/ssl/cert.pem until they push an update

they also have to consider that such users may have custom changes to their cert.pem file, and they probably don't want to rush an update that would potentially fu-bar those changes

Affiliations aside I think I'm happy to see shade thrown at anyone who hasn't bothered to even issue a patch 10 days after what has been one of the biggest news weeks in security in memory.

Fwiw, as critical as I am of Mozilla in recent years, they (along with the Chrome team) have been pretty solid on this whole debacle over the last week. Apple has been far from the only target of their collective shade-throwing.

Your apps and browser don't trust them. Why should your CLI. It's easy and warranted for Apple and look how much cash and engineers they have.

Apple should publish a hotfix now. Work on a better solution in the long-term. They just don't care about security for developers is my take (it's like a niche group for them?)

Mozilla or not does not matter here.

A concern for me on this site is that they give the shell commands to edit the /etc/ssl file on their site, instead of just making the Apple link (which they also list) as authoritative on the matter. I don't think users should get in the habit of cut/pasting sudo enable shell one-liners from "random" websites, especially and specifically when the vendor has the very same commands in their published fixed for the issue. In short, this site should have just said "go get the fix from apple".

What? Who's still using MacPorts?

Did you misread the title?

> A flat cert.pem file (or similar) can't say "distrust this intermediate".

Why does that matter in this case? Can't this be fully mitigated with next to no collateral damage just by removing the trusted roots that signed them?

I reposted this as it wasn't clear from previous comments with this URL that there's a patch that's worth running in there from Apple themselves