"Ten days later, macOS and all applications that rely on it still trust the compromised eMudhra certificates" would have been a better title.
Apple fucked this up, but I really don't think the situation is "as bad if not worse" than if MacOS just didn't do this.
> kubernetes
If only we could somehow share libraries and configuration files across apps rather than duplicating them and having to update them for every app individually.
We could call it a "shared library" system and an "operating" system. Someone should really invent this.
I mean, even docker could maybe use a shared base image or something right? ;-)
There’s very little actually running in a docker container. ca-certs may actually be an exceptional case though, since it’s not code that’s running but a kind of data.
It’s not like if you use an Ubuntu image for a node.js app that you get PHP too and have the PHP vulnerability present in your web app.
It's same problem we have when libraries get massive security vulnerabilities. Updating them is not always as easy as many would like.
This gets worse for each additional such layer, for example if you start from ubuntu:whatever and have a system deps layer, then an application deps layer, then static assets, then your app's code. Unless you think about it upfront when designing the pipeline, it can be challenging to trace all that state backwards and figure out how to safely re-build thing-from-x-weeks ago but with a single unsafe package bumped forward.
Every shop with competent devops people present should be set up for this, but it usually doesn't come for free.
That version of copy overlays the copied content without any knowledge of its underlay, so if the underlay changes, the hash of the layer created by COPY remains identical.
Obviously there are lots of situations this doesn't work for, but say you have a pool of Ubuntu packages (the system layer) and then you separately copy a CMake installspace or built uv project from a build stage, that project layer can be identical in hash if it's copied onto an updated system layer.
In practice, it's hard to get this to work because it's very easy in docker to accidentally trigger a rebuild for some random reason, but all the pieces are there.
That's the world we live in now thanks to Google and Mozilla.
It's also worth remembering that both of these specific organizations were instrumental in major, positive security shifts that eventually hit OS's too, including shorter-lived certs, limiting the point of CAs, adoption of TLS 1.3, and likely other things. If anything, they deserve _more_ trust than the OS distributors on this specific front, perhaps also because they don't share the OS distributor's incentive to prioritize stability for paying customers, which can be at odds at times with harsh, prompt security measures.
But this abstract exercise is only to highlight the importance of Apple getting its shit together, because such a scenario exists with Windows and the culture of downloading exes and msis and it's honestly way worse than having a central but responsible authority.
Tangentially related: I fucking hate so much that browsers now all have their own DNS resolvers and caches, it's just Another Fucking Thing to debug when you're working especially on locally hosted stuff. This is not a browser's job, it's a task that should fall to the OS.
Edit: Found it, February 2020: https://blog.mozilla.org/en/firefox/firefox-continues-push-t...
Out of curiosity, what are some of those things it messed up for you? And what kinds of builds is it affecting?
And like, I don't need that. My DNS server is properly maintained and queries those exact same servers itself when you request something like google.com or apple.com. Putting a separate friggin DNS query AND cache in a browser is just more trying to protect people from themselves IMO, and introduces this weird issue where you can't hit an internal site in Firefox, even though you're running `nslookup` on your freaking computer, and it's giving you the proper IP address. And paradoxically putting the IP address in makes the browser find it when the domain you can see correctly resolving in terminal isn't resolving in the browser is fucking obnoxious.
It also would render a pihole useless because Firefox despite the PC's DNS not resolving ad provider's names, WILL resolve them, ensuring an attack vector for malware remains wide open even if you've tried to close it.
And while I'm bitching about this: STOP DEFAULTING EVERY CONNECTION TO HTTPS. Any properly configured website is going to do this anyway, the browser also doing it, again, just annoys the piss out of anyone trying to host stuff locally because why the fuck would I get certificates for servers that aren't even exposed to the damn Internet!?
Attackers won't do it. The browser itself has to put barriers in front of http for public domains.
But yeah it shouldn't get so fussy for local IPs or local DNS.
Both from a sheer numbers perspective and also from the perspective of qualitative differences between these audiences browsers are doing the right thing - prioritizing security in low-to-no-trust environments assuming low-to-no-competence administration.
Welcome to hell. https://en.wikipedia.org/wiki/DNS_over_HTTPS
(My current chrome reports no at https://one.one.one.one/help/ so maybe I changed it or maybe the default's different now)
Certificate management is fifty kinds of all messed up - and in THEORY everything is designed perfectly and properly, in practice it's all bandaids on bandaids that nobody cares about as long as "things mostly work".
So from a spherical cow perspective, it's well-designed; from a "this has to work in the real world with real things and people" it's ... workable by violation of the design all the time.
Is it possible for users to remove the eMudhra certificates themselves? I have no experience with MacOS, so I don't know if certain actions are prohibited. To be clear: I am not suggesting that normies do this! Rather, I am asking if it is possible for highly skilled users.
Edit: Git is still affected, we're fixing that now.
(Source: I am one of Homebrew’s maintainers.)
There's a fix incoming here[1].
> Homebrew ships its own CA bundle
Outside of an enterprise environment, I never thought about having multiple "golden sources" of CA certs on a single host. (I have no experience working outside of classic enterprise environments, so please do not read my surprise as immediate dismissal of this idea!) For those unaware, in enterprise environments, it is very common to use a common CA cert pack from Oracle/Mozilla/Google/Microsoft/Amazon/Apple, but add 2-5 CA certs from your own company that act as trust roots.
I did some Googling on this matter. It looks like the "Big Four" of CA cert packs are: Mozilla, Microsoft, Apple, and Google. (I guess there is one or two in China also, be leave that alone for the moment.) What happens if they are in disagreement? This is a complex problem! If anyone is involved in this process, I would like to learn more.
Not easily, because it's closer to a convergence of smaller engineering decisions into an emergent choice to ship a CA bundle.
But the short version: lots of tools ship their own CA bundle. This is not ideal for distributors like Homebrew, because people expect one CA root program for the entire distribution. As a result, Homebrew tries (and sometimes fails) to apply a consistent root program across its tools. Apple's own roots are not inherently best suited for all Homebrew users, so we end up shipping a composite of their roots and the Mozila root program.
> What happens if they are in disagreement?
They are in disagreement, all the time! Root program operators are totally free to manage their trust roots as they please. The only forcing function is a desire to honor users' connections; differences in root programs end up getting papered over somewhat by cross-signing between different CAs.
> lots of tools ship their own CA bundle.
With the exception of Java, on a modern enterprise Linux box, all packages use the same CA cert pack.
Edit 2: This is being fixed now[1]. Everything below is stale.
I couldn't reproduce this:
% which git
/opt/homebrew/bin/git
% git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
fatal: unable to access 'https://git-emudhra.we-have-a-problem.com/check.git/': SSL certificate problem: unable to get local issuer certificate
$ git ls-remote https://git-emudhra.we-have-a-problem.com/check.git && which git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD
2975b9930644b321e18ecae09e29c15b955e6103 refs/heads/main
/opt/homebrew/bin/git
$ brew list git --versions
git 2.56.0_2
$ which git
/opt/homebrew/bin/git
$ which curl
/opt/homebrew/opt/curl/bin/curl
$ git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD
2975b9930644b321e18ecae09e29c15b955e6103 refs/heads/main
I would've preferred a doc or a code repo link as a source. Otherwise, this just reads like a brag. A decent one, to be fair :)
(Sorry if you thought it was a brag, it’s just supposed to be context so that everybody is on the same page about the reason for a comment.)
I understand why they originally let each CA in, but it's definitely not one size fits all users.
A user in the US does not need to trust a Turkish CA the same way a user in Turkey does.
There needs to be an easy way for end users to personally drop trust of CAs they don't need and have that decision respected and remembered.
There is. On macOS go to Keychain Access > System Roots and disable the kind of trust you want to disable. There's probably a scriptable method for that.
On Windows, open the management console to "Certificates". Then go through the list and move/remove/distrust any certificates you dislike. There are also powershell tools you can use.
On Linux, the situation is a bit annoying. You can remove all CA certificates manually and make the directory read-only to break any attempt from your distro to interfere with the list. You need to check your distro documentation to see if they use /etc/ca-certificates or /etc/ssl or something like /etc/pki for reference. Some distros offer a partial GUI as well.
Programs that deem themselves smarter than the OS (true in the case of macOS and various Linux distros), like browsers, the JVM or NodeJS applications, can have their own cert stores.
You will need to acknowledge half a dozen certificate prompts for every website you visit after this, though. Make sure to compare the fingerprints of the CA root certificate with the real ones you might find elsewhere, because it's easy to generate your own CA and copy all certificate information signed by your self-generated key.
- Only ISRG(Let's encrypt) being the sole CA and benevolent dictator of the internet. (then forced to be dissolved due to antitrust?)
- Each country controls their own CA and you need to purchase 200+ certs in order to make your website generally accessible. (then country XXX will charge you $200/year)
- Big techs owning OS/Browsers control their own CA and cross license each other (then Apple still being lazy handling incidents) (then they form a cartel and block others, like current Tier 1 ISP, email senders, credit card networks)
edit: put enter between numbered items.
If I can speculate though on why these bundles come from the browser or OS and aren’t fully in the user’s responsibility. You’d have to start from scratch for it to not have a bunch of stuff the user had ‘no need for’ to be present, and the user would need to see a cert window semi-frequently that gives the possibility to start trusting a CA, and the bottom 99.99% of users in sophistication has no idea whether they should say yes or no. I mean, without being signed by a root CA you already trust, even the name on the new CA could be completely made up. “Do you want to trust the ‘Apple Root Certificate Authority’?”
But even if not, you get asked whether to turn on Siri, whether to send telemetry, whether to sign away your rights, etc., all of which are consequential but prompts are massaged in a way where it's nice and easy for the user to answer a certain way without having a clue. Makes me think user comprehension isn't even a problem.
Where I suspect the problem lies is that it will not fly to make it seem like US-based CA's are more trustworthy just because the majority of sites roll up to them. Then you'll need to do some non-country-specific human tiering, and who's the judge of that?
So what happens to americans visiting french sites?
[Do Not Trust], [Trust Once], [Trust Forever]"
The country comparison doesn't do much either, because there isn't a good guarantee that they'll correspond. Some guy posted a repo to distrust every CA except the top 30, and that has a bunch of weird examples, like a bunch of russian sites being signed by a Greek CA. Not to mention some of the biggest sites use CAs that don't correspond with their country of origin. GlobalSign is Belgian for instance. Guess how many of their customers aren't Belgian?
You can add other options too, "Trust for 30 days" or something. I wish SSH known hosts has an auto-expunge.
So someone has to do it, and a pop-up on first boot asking you which "certificate providers" you want to trust would be as pointless as the "which browser do you want to use" ones were.
Thanks for being on the ball, Apple.
I don't know why they haven't rolled out an update if they've already wrote a whole article about patching the problem yourself.
But instead the Apple fanboys will be out in force to tell us why actually its a good thing for Apple to leave parts of the OS insecure.
Better luck next time.
It really surprised me what mobile devs put up with, just an utterly horrible hostile experience.
I have no idea how you've come to this conclusion, and clearly nothing of the sort is actually going on here.
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?
For your tool, remember to nuke Windows' automated certificate authority updates (separate from normal Windows updates) and possibly the automated intermediary cache. Microsoft publishes a list of trusted CAs/intermediaries periodically and they get automatically applied to Windows so websites don't need to send the full cert chain during TLS negotiation, and it has a tendency to cache trusted intermediaries as well.
Mozilla's trust store is one of the first to get updated when a revocation happens, as well as Google's CRLsets. Downloading full CRLs repeatedly would be a waste of time and bandwidth, that's why there's a specific distribution method for CA updates. I would extend your tool with a daemon that checks for revocation automatically, so you don't accidentally eMudhra yourself while browsers and the OS get updates next time something like this happens.
This feels like all of the C code getting attacked now where everyone spent the last three decades building up cruft because fixing it would be a chore, and now the separate bills are coming due all at the same time.
Then someone would ask "there has to be a better way" again, when the reason for the new inconvenience gets forgotten, and it oscillates.
Not great for unaware developers, but most macOS users are fine. Those who are aware can follow the steps in https://support.apple.com/en-us/149555 until Apple bothers to roll out an update.
Fundamentally, people don't want to think about the intricacies of how we decide whether or not to trust a particular cert. They want it to just work without thinking about it. This includes that if they have a custom private root they need to trust, they just drop it various places until it starts working and call it done. And sometimes they do weird things like adding intermediates to their trust store because they were trying to call a service that has their cert chain configured incorrectly, and that "fixes it". Again, it's a nightmare.
The fact that linux, a system notoriously cobbled together by 873 different factions on the internet, is even more of a mess is not surprising in the least.
I suspect the fast-track background security updates can only update the databases and revocation lists that live in the proprietary APIs, not any arbitrary file on the system
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.
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, and maybe this is what Apple should have done (it’s the workaround they recommend!). But it means that some small percentage of certificates that are fine won’t be accepted.
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.
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
Whatever reason Apple had for not updating /etc/ssl/cert.pem yet, I am certain it's not out of consideration for users that might have put custom certs in there.
not convinced? take a look at your /etc/ssl/cert.pem
Well looks like they should take the hint from a better vendor such as Debian then :)
Pretty much every developer on mac should probably run their patch.
Per https://emudhra.we-have-a-problem.com/apple.html
> 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.
Apple, for the company that prizes itself on believing privacy is a human right, why are you failing your customers so badly on PKI management?
It’s completely insane to me that Apple didn’t script this with interactive prompts as needed, and non-interactive options for automatic installs.
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.Tools common on Linux like curl and git come with the OS basically for developer convenience. Apple doesn't write those programs, they don't use Apple's APIs or platform features, and thus in some sense you aren't really meant to use them in Apple's eyes. Ports of UNIX CLI tools exist in a kind of semi-supported netherworld on macOS. They run but they aren't fully integrated or supported parts of the OS.
That doesn’t seem to be the case at all. I’d wager that in Apple’s eyes you’re very much meant to use these tools, they just expect you to know what you are doing if you go down this route.
This is technically a problem in the CLI - it needs to support revocations properly, not rely on root CA verification only. I’m not sure though whether there’s a standardised mechanism (that Apple supports) for CLIs.
> These steps affect every tool that uses /etc/ssl/cert.pem. Afterward, tools that use only this file might not be able to verify some websites whose certificates chain to these root CA certificates through intermediate CAs that weren't affected.
Not sure why macOS doesn’t ship such a build of curl.
So the only way to fix apps that don’t handle revocation of intermediates (eg the ones that only look at certs.pem) is to revoke the root.
Great, that’s fine. They can reissue.
The writing is on the wall for the command line tools.
(We can already see this tooling devaluation happening all over the place. Apple have their variant of this response to the AI tooling-paradigm tsunami…)
I’m not saying they’re going to deprecate XCode today, but I do believe they will “agent’ize” Developer Tooling drastically in the next year or so. Agents are becoming the most important user of command line tools.
Because they have to, in order to catch up with NVidia, their only real competition. If you want to understand why I think that, its because I have been developing and deploying cross-platform Linux-centric (but MacOS and Windows targeting) applications, mostly for the ARM platform but also with Intel (SIMD on both) .. for the past few months, and I haven’t touched an IDE in a month. On DGX Spark. Which turns out is a truly, utterly, mind-blowingly great platform to do cross platform high performance application development…
CLI is just a thing that NeXT had and even that made it easy to use GUI tools.
Xcode is a GUI tool – it happens to expose some cli tools but they could be covered up – however some developers would complain a lot so I don't see that happeneing.
The original question is, why aren’t Apple fixing the CA problems for the command line tools (whereas they have done it for .app’s such as Safari), and the reasoning is, because the user will just have to fix it themselves, because Apple don’t care about the command line users - they see that these command line tools are, indeed, becoming the front-line for agentic development, so .. presumably, they have an .app bundle which does away with this problem, to be shipped on the horizon ...
Anyway, its just a theory.
I wonder why they stopped doing that and now just seem to do "standard" builds and end up with this (at least) 2 separate trust store situation.
They might need to make a way to do this outside of os updates
Their attitude seems to be that you don't own anything outside of your homedir, and touching system-managed files is done at your own risk.
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.
So, I do agree this could be problematic, on specific cases where people not using a major browser were accessing resources some is interested on, on a network they have control of. Makes the surface quite small.
The threat here is more so for 'backend' services than regular browser users.
There are people from these CAs who were denied in the past explicitly for concerns about spying who now work at eMudhra[3,4].
0: https://bugzilla.mozilla.org/show_bug.cgi?id=1474556
1: https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
2: https://groups.google.com/g/mozilla.dev.security.policy/c/nnLVNfqgz7g/m/TseYqDzaDAAJ
3: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c43
4: https://emudhra.com/en/blog/scott-rea-joins-emudhra-as-senior-vice-president-global-strategic-advisor
https://fullmetalmac.com/cybersecurity/macos-security/xprote...
You're either not an Apple user, or never noticed Settings → General → Software Update → Automatic Updates
https://support.apple.com/en-us/102657
The big question is why they’re not using it for things like this, where a tiny layered file system update would benefit almost all of their users immediately.
Editing to add a link to this Apple support article which is unsurprisingly detailed - https://support.apple.com/en-us/149555
Similar reason (though with the opposite effect) as how a cert can be fine for browsers but fail for curl when they don't send an intermediate: the "vanilla"/library/command-line stuff is just checking for a path to a trusted cert and not doing the CRL or AIA stuff a browser does.
CLI-based activity references etc/ssl/cert.pem. While they say this will be updated in the future (likely the next dot release), admins can also proactively remove the eMudhra entries.
macOS already has the verifier needed (Security.framework/trustd path that protected Safari). It would be good if MacOS routed CLIs through it.
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?
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, but it means that some small percentage of certificates that are fine won’t be accepted.
If I’m an OS vendor I would have been putting them on notice days ago that their root was being dropped and they have X days to reissue certs and deliver a new root cert or otherwise they can just accept that they’re not qualified to be a root anymore.
yeah, it's not ideal but the scale of the threat is way overblown tbh. You have to compromise a lot to be able to make a MITM here.
Let's not treat it like PHP2Shell.
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.
xz-tools was only caught because it had a bug causing slow startups and someone was micro-benchmarking Postgres and decided to dive in further.
I agree it's not PHP2Shell, but its certainly not being "way overblown" here.
Users will be none-the-wiser because they're not accessing these hosts through a web browser, and you net a few more compromised hosts in your inventory.
Edit: Holy moly we all jumped on this comment at the same time didn't we.
It's good to see push back against this narrative that is trying to develop that this isn't any kind of big deal.
This has been every machine on the internet compromised for at least 12 hours and probably some that are not going to ever get patched.
This is a HUGE deal for embedded devices, we can now mitm HTTPS traffic on lots of embedded devices running Linux produced between 2018 and now.
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).
Either way, I mean rouge in the sense of an AP that uses the same SSID and password as the AP of a coffee shop or office to have devices automatically connect to it without their users noticing.
“Rogue” is a completely different word. Rogue access point.
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.
If you get past all of that, you still need a victim who is actively using a cli tool on macOS using https.
It’s not impossible, but the conditions are much more specific than those needed to inject porn into a webpage on a poorly configured school network in 2006.
So you need to somehow trick macOS into remotely connecting to the wrong bssid, and then arp poison a user who happens to be using a macOS cli tool that’s using https.
Sounds pretty targeted and unlikely to happen.
I don’t think that’s either targeted or unlikely?
I just set up my phone's hotspot to be the same SSID and password as the network the robots already know from the office, and I'll have the robots, a couple phones, and a laptop connected in 10 seconds.
Yeah that's not so much "trivially easy"
I hazard that the answer to all three of those is "yes".
yeah, it's trivial to punch somebody in the face in the morning, all you need to do is to be by their bad in the morning when they are waking up.
If you think it's not that important, it becomes a critic about TLS and basically saying that ciphers for web traffic are useless.
Physical access to networks isn't that hard to come by.
Regardless, real bad actors are busy compromising your next `npm install` anyway. Much better reward.
If someone has it in for you and hired a high skill attacker, its not a stretch to imagine they compromised your home network.
Why are you assuming there isn’t someone else trying to hack you at the next cafe? Actual damage can happen one person at a time, and can occasionally lead to larger scale compromises. Randomizing your location isn’t going to reduce your risk. Now that everyone who’s paying attention knows they can MITM your Mac, you shouldn’t trust any network.
You'd be better off just mugging them in the parking lot.
Except it won't impact gmail unless you're accessing it through curl. The browsers already distrusted the compromised intermediates via CRL within hours of disclosure, and removed the affected root via update.
What if it's the Starbucks at 1730 Pennsylvania Ave NW, Washington, DC 20006 for an extended period of time? Compounded with other security issues like password reuse...
We can always draw a line and say, "that's not practical". The assessment an attacker is likely to do is going to be "is this practical inside my budget for the value I hope to acquire?" or maybe even just "waow, lulz".
So this isn't like Firesheep [0]. Yes, there would be vulnerable traffic, like the git client this thread is discusing, but it's not "everything"
This is just an argument against TLS in general. Use plain http if you believe this.
I’d also bet more things use libcurl behind the scenes than we appreciate, and that at least a few of them have things like silent updates which retry after a failure without notifying a user. I’ve seen a lot of agents which just try to periodically check in because they’re designed not to be noisy on lousy networks.
Source: https://mstdn.social/@jschauma/117513596272504904 https://mastodon.social/@glyph/117509558825919922
# /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
Your client successfully connected to the site. That's bad!
# sudo mv /etc/ssl/cert.pem /tmp/
# sudo ln -s /opt/local/libexec/openssl3/etc/openssl/cert.pem /etc/ssl/cert.pem
# /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.htmlWindows 11 is awful, lots of the fixes and modernization started in windows 10 has totally stalled, leaving users with 5 different places to change a setting instead of the one old place or one new place. Look how many different UI's there are to adjust sound card / sound settings or display settings. It's a complete mess. Their attempts to jump into the AI game have been a complete joke, despite already having integrated Cortana years ago. Putting Cortana on an llm is such an obvious thing to do, and they already did so much work to make that fully integrated into windows and force it on everyone even though it was trash, and now it's still trash and they don't seem to be able to adapt at all.
Now they can't respond to a complete insecurity in one of their major products in weeks? Why do they even validate certs? Why doesn't revocation work in their app? I don't think they can really be trusted at this point.
On one hand there’s unmaintained packages that won’t update dependencies. On the other hand, fixed dependencies did not necessarily backport to all possible versions in the wild, making update as a fix unviable for those.
If you are finding yourself not trusting eMudhra anyway, then you might want to choose an OS that lets any well vetted and capable security researcher in the world contribute to it.
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?
It's not like they cannot introduce a bad certificate right now. We would be just be taking the ability from all other countries from doing the same.
Upstream was involved in it as well. Sure it was a communication problem, but it's not like the maintainer just decided to this unilaterally. Also this WAS undefined behaviour, so from a language perspective it was already broken, even if it worked accidentally in practice.
One that mixed uninitialised data to the entropy pool.
And another one that mixed initialised data to the entropy pool with the exact same function call. Which was, in fact, almost all of the entropy.
I don't think its wise to make current security decisions based on screw ups from almost 2 decades ago.
I don't really care one way or another. I use Linux and I use macOS. But I'm not naive to think the security is any better in one or the other.
Do you use macOS? Because if you did, then how did you recover from them allowing anyone to straight-up log in as root without password? And then mess up the fix for that bug? That wasn't 2008, that was 8 years ago.
Then as it has been 2 decades you should be all good right?
If that's the worst you have against Linux then it looks like it has done very well.
And not just GMail, this was virtually every service out there. From a perspective, it's laughable how bad security was back then.
Morality doesn't solely depend on action or inaction, it also matter what you act or don't act to.
Besides, how does this relate to my Linux point, where no one installs anything without you knowing it?
How is that worse than NOT having any sort of fix from Apple?
However, there is certainly a chance that Apple team didn't think the impact was that bad given all the other protections in place.
When Steve Jobs was alive, his Apple company email was leaked and published and Apple customers emailed him for features and fixes all the time and he personally responded once a while. Tim Cook did the same a couple times too. Perhaps the blog author should write in to the new CEO John Ternus or SVP of Software Engineering Craig Federighi too to see if they can fix that.
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above. $ 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!It's totally wild that there isn't an interactive script/check already built to test, detect, and run the solution on all fronts.
And there's a lack of motivated attackers for a reason, the attack scales poorly. Maybe you can bamboozle a target or two, but if you go for hundreds, somebody's gonna start wondering what's up with the keys. If you're trying to take over the world, or sell to somebody who is, you're better off focusing on compromising a root of trust or tampering with name resolution, because attacks like that are sustainable at scale.
If you're worried that you'll be targeted as an individual by somebody who cannot coerce a CA but can tamper with the channel you're using to get the public key, use https.
If you're worried that you'll be targeted along with many others by somebody who can coerce a CA, use ssh and ensure that some folks are comparing key fingerprints such that at least one is close to the source.
Seems like via AI everyone is discovering their systems are compromised. Can’t blame Apple for making the discovery. 10 days and no patch is another story.
Hope they get it together and fix this soon.
https://gist.github.com/hbmartin/d485b07691d9dc2a66937f50719...
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.
I applied those commands.
Then, last night, I applied the macOS 15.8.2 from Apple.
Voila, the eMudhra certificates were back. :-(
So I re-applied those commands once more.
Come on Apple, you can do better than that!
This is just another one of those smells.
It should be "Apple still ships compromised CA in /etc/". Git is just a victim like every other app using system CA
(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 :)
That is unequivocally bad, similar to Java which ships its own keystore.jks and many applications shipping its own copy on top of that. True nightmare fodder.
And curl was patched to use the native TLS implementation (SecureTransport) which obviously used Keychain as well.
For some reason when they switched to LibreSSL everywhere they decided to ship their own copy? I don't know what they were thinking.
At least for that, in $OLDJOB I went and created a new keystore.jks myself to account for an internal CA, so my successors can just update that file, restart the containers and that's it...
Yes, and that makes not dealing with this issue worse on Apple's part. If MacOS' setup somehow doesn't allow untangling a (still deemed trustworthy?!?) root certificate issued by eMudhra from the broken intermediate certificates, then revoke that whole chain including the root & accept collateral damage.
Failing that just provides an incentive for apps to do their own chain-of-trust implementations. Which like you said is not the way to go.
In reality it's macOS shipping the outdated certificates, and it affects various other command-line tools, like Curl.
"Ten days later, Apple Image Viewer on macOS still trusts the compromised eMudhra certificates" doesn't sound as catchy, but is equally correct because the apps use system CA.
Macs have two completely independent root CA stores. The cli and all the opensource parts use /etc/.
Curl project did actually release support to compile it with default keychain support a year ago, but of course Apple never updates their cli tools, so expect to see that in macOS 37.
Note: I’m not defending Apple here.
Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.
Of course they would throw shades at Apple. That being said the situation isn't ideal and I'm sure Apple would have shipped an update if it were easy and warranted.
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.
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.