> 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.
This isn't entirely accurate. Plenty of apps run Terminal commands in the background (for some reason). For example Rewind.ai (before they got acquired and installed a kill switch, Adobe Flash-style) runs `top` every two seconds, presumably to figure out its own CPU usage. What the fucking shit? But I think it's not out of the question that other apps run other crap too.
Also, if they didn't care about Terminal users, they would not have even published this article!!
> This isn't entirely accurate. Plenty of apps run Terminal commands in the background (for some reason).
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.
You're right, that was just the example I had on hand. Maybe a better example could be something like a video downloader that bundles yt-dlp, that could end up using this certificate store rather than the Apple APIs.
They published the article for the people they care above, to make it clear to them they should not worry about all these reports about Apple being vulnerable to this issue.
Good on Apple for providing such a detailed article. Fuck everyone who thinks they're doing badly by not updating this file remotely on current software versions in the wild -- most likely their Rapid Security Responses / Background Security Improvements framework does not already support this file (though perhaps it will), which is why they state a full operating system update will be required. Being transparent and open about what administrators can do about this now is the RIGHT APPROACH, and no other vendor has been nearly as thorough about this.
Google, Microsoft, Mozilla, several TLS libraries and language runtimes, and even many Linux distros run by volunteers had this issue comprehensively fixed over a week ago: https://emudhra.we-have-a-problem.com/#developers
Meanwhile, it's unsafe to run `git clone` on macOS unless you manually edit some files, and then edit them again after a macOS update puts the dangerous root certificates back.
Apple has been the most thorough in documenting this transparently and honestly. They didn't have the process for updating that file in the wild, and most likely that will be fixed.
Apple security updates, especially automatic ones, likely don't have the capability to simply write to arbitrary files on the system or run arbitrary commands at install time. Of all vendors, certainly from Apple I'd expect this.
Most likely, other vendors either already used a similar store as the root of trust system-wide (didn't have their own separate security stacks), or their security updates do have the ability to write anywhere or do anything.
And of course, Linux distros and other platforms where the component can be updated separately from the operating system have an even easier time.
This is not Apple intentionally leaving terminal users high and dry. The article literally is the proof otherwise while they no-doubt work on a better solution.
I'm sorry, but how is revoking a bad cert not supported in an easy way? Along with adding a cert and using it to establish a secure connection, that seems to be the core features of a cert store?
Yet somehow, you manage to come to the conclusion that the vendor requiring manual work is the most thorough? I mean, in documenting their failure, maybe.
With all their talk of caring about user privacy, this seems incompetent at best.
The article warned of this already (re-applying the fix after updates). That update was likely already in the pipeline before this debacle. No one can say for sure though.
They're doing badly because they have a market cap at 5 trillion USD ($5,070,000,000,000 to $5,110,000,000,000) and chose to ditch the first principals of a CA store. Doing impressive backflips to compensate for lack of understanding first principals is exactly that.
Can you explain what first principles you mean? /etc/ssl/cert.pem has been a fairly standard convention on BSDs, and Linux distros usually have an equivalent somewhere too, like for example /etc/ssl/certs/ca-certificates.crt.
I don't blame Apple for overlooking it when they have their own security stack that all their own apps use, which already responded to the incident within two hours of the revocation. As another commenter pointed out, Terminal commands probably just weren't a priority of their threat model. I do hope they fix that, but mentioning their market cap is not gonna help here.
It's on the front page right now. Their dev tools are a complete mess when it comes to actually using the trust store as designed. Why would you dismiss this outright?
I'm not saying it doesn't matter that dev tools are affected. Those are perhaps some of the most important tools and riskiest to leave vulnerable, because that could result in malware shipped to users from a trustworthy developer, or malware executed on the developer's machine, rather than simply phishing. I just don't think it's fair to assume they did it intentionally. It's a mistake, and one that should be fixed, don't get me wrong. But there's a reason it happened and that seems fair enough to me.
> 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.
What a clusterfuck
> If you don't use Terminal as part of your workflow, you don't need to do anything.
they solved the issue for the people they care about
This isn't entirely accurate. Plenty of apps run Terminal commands in the background (for some reason). For example Rewind.ai (before they got acquired and installed a kill switch, Adobe Flash-style) runs `top` every two seconds, presumably to figure out its own CPU usage. What the fucking shit? But I think it's not out of the question that other apps run other crap too.
Also, if they didn't care about Terminal users, they would not have even published this article!!
> This isn't entirely accurate. Plenty of apps run Terminal commands in the background (for some reason).
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.
You're right, that was just the example I had on hand. Maybe a better example could be something like a video downloader that bundles yt-dlp, that could end up using this certificate store rather than the Apple APIs.
They published the article for the people they care above, to make it clear to them they should not worry about all these reports about Apple being vulnerable to this issue.
Related: Ten days later, Git on macOS still trusts the compromised eMudhra certificates https://news.ycombinator.com/item?id=50271640
that should really be a security update
It is, isn't it?
Apple states in the article that a full operating system update will be required to fix the file.
Good on Apple for providing such a detailed article. Fuck everyone who thinks they're doing badly by not updating this file remotely on current software versions in the wild -- most likely their Rapid Security Responses / Background Security Improvements framework does not already support this file (though perhaps it will), which is why they state a full operating system update will be required. Being transparent and open about what administrators can do about this now is the RIGHT APPROACH, and no other vendor has been nearly as thorough about this.
Google, Microsoft, Mozilla, several TLS libraries and language runtimes, and even many Linux distros run by volunteers had this issue comprehensively fixed over a week ago: https://emudhra.we-have-a-problem.com/#developers
Meanwhile, it's unsafe to run `git clone` on macOS unless you manually edit some files, and then edit them again after a macOS update puts the dangerous root certificates back.
In what world has Apple been the most "thorough"?
Apple has been the most thorough in documenting this transparently and honestly. They didn't have the process for updating that file in the wild, and most likely that will be fixed.
Apple security updates, especially automatic ones, likely don't have the capability to simply write to arbitrary files on the system or run arbitrary commands at install time. Of all vendors, certainly from Apple I'd expect this.
Most likely, other vendors either already used a similar store as the root of trust system-wide (didn't have their own separate security stacks), or their security updates do have the ability to write anywhere or do anything.
And of course, Linux distros and other platforms where the component can be updated separately from the operating system have an even easier time.
This is not Apple intentionally leaving terminal users high and dry. The article literally is the proof otherwise while they no-doubt work on a better solution.
I'm sorry, but how is revoking a bad cert not supported in an easy way? Along with adding a cert and using it to establish a secure connection, that seems to be the core features of a cert store?
Yet somehow, you manage to come to the conclusion that the vendor requiring manual work is the most thorough? I mean, in documenting their failure, maybe.
With all their talk of caring about user privacy, this seems incompetent at best.
Where exactly is it good, that:
* apple told admins how to fix the vulnerability * apple shipped update 27.2, with no fix (today) * the update reverted the admin fix quietly
The article warned of this already (re-applying the fix after updates). That update was likely already in the pipeline before this debacle. No one can say for sure though.
They're doing badly because they have a market cap at 5 trillion USD ($5,070,000,000,000 to $5,110,000,000,000) and chose to ditch the first principals of a CA store. Doing impressive backflips to compensate for lack of understanding first principals is exactly that.
Can you explain what first principles you mean? /etc/ssl/cert.pem has been a fairly standard convention on BSDs, and Linux distros usually have an equivalent somewhere too, like for example /etc/ssl/certs/ca-certificates.crt.
I don't blame Apple for overlooking it when they have their own security stack that all their own apps use, which already responded to the incident within two hours of the revocation. As another commenter pointed out, Terminal commands probably just weren't a priority of their threat model. I do hope they fix that, but mentioning their market cap is not gonna help here.
It's on the front page right now. Their dev tools are a complete mess when it comes to actually using the trust store as designed. Why would you dismiss this outright?
https://emudhra.we-have-a-problem.com/apple.html
I'm not saying it doesn't matter that dev tools are affected. Those are perhaps some of the most important tools and riskiest to leave vulnerable, because that could result in malware shipped to users from a trustworthy developer, or malware executed on the developer's machine, rather than simply phishing. I just don't think it's fair to assume they did it intentionally. It's a mistake, and one that should be fixed, don't get me wrong. But there's a reason it happened and that seems fair enough to me.