Apple Criticized For Changing the macOS version of cURL (daniel.haxx.se) 75
"On December 28 2023, bugreport 12604 was filed in the curl issue tracker," writes cURL lead developer Daniel Stenberg:
The title stated of the problem in this case was quite clear: flag -cacert behavior isn't consistent between macOS and Linux , and it was filed by Yuedong Wu.
The friendly reporter showed how the curl version bundled with macOS behaves differently than curl binaries built entirely from open source. Even when running the same curl version on the same macOS machine.
The curl command line option --cacert provides a way for the user to say to curl that this is the exact set of CA certificates to trust when doing the following transfer. If the TLS server cannot provide a certificate that can be verified with that set of certificates, it should fail and return error. This particular behavior and functionality in curl has been established since many years (this option was added to curl in December 2000) and of course is provided to allow users to know that it communicates with a known and trusted server. A pretty fundamental part of what TLS does really.
When this command line option is used with curl on macOS, the version shipped by Apple, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification. A secondary check that was not asked for, is not documented and plain frankly comes completely by surprise. Therefore, when a user runs the check with a trimmed and dedicated CA cert file, it will not fail if the system CA store contains a cert that can verify the server!
This is a security problem because now suddenly certificate checks pass that should not pass.
"We don't consider this something that needs to be addressed in our platforms," Apple Product Security responded. Stenberg's blog post responds, "I disagree."
Long-time Slashdot reader lee1 shares their reaction: I started to sour on MacOS about 20 years ago when I discovered that they had, without notice, substituted their own, nonstandard version of the Readline library for the one that the rest of the Unix-like world was using. This broke gnuplot and a lot of other free software...
Apple is still breaking things, this time with serious security and privacy implications.
The friendly reporter showed how the curl version bundled with macOS behaves differently than curl binaries built entirely from open source. Even when running the same curl version on the same macOS machine.
The curl command line option --cacert provides a way for the user to say to curl that this is the exact set of CA certificates to trust when doing the following transfer. If the TLS server cannot provide a certificate that can be verified with that set of certificates, it should fail and return error. This particular behavior and functionality in curl has been established since many years (this option was added to curl in December 2000) and of course is provided to allow users to know that it communicates with a known and trusted server. A pretty fundamental part of what TLS does really.
When this command line option is used with curl on macOS, the version shipped by Apple, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification. A secondary check that was not asked for, is not documented and plain frankly comes completely by surprise. Therefore, when a user runs the check with a trimmed and dedicated CA cert file, it will not fail if the system CA store contains a cert that can verify the server!
This is a security problem because now suddenly certificate checks pass that should not pass.
"We don't consider this something that needs to be addressed in our platforms," Apple Product Security responded. Stenberg's blog post responds, "I disagree."
Long-time Slashdot reader lee1 shares their reaction: I started to sour on MacOS about 20 years ago when I discovered that they had, without notice, substituted their own, nonstandard version of the Readline library for the one that the rest of the Unix-like world was using. This broke gnuplot and a lot of other free software...
Apple is still breaking things, this time with serious security and privacy implications.
Sounds like criminal computer sabotage (Score:2)
Too bad that no prosecutor will care.
Re: Sounds like criminal computer sabotage (Score:5, Interesting)
The difference in behavior is due to differences in the SSL library curl is linked to. That behavior is not even formally specified, the man page even makes it clear that flag is platform specific right out the gate before even getting to the platform's SSL implementation.
And then... why is anyone using curl to do very specific SSL validation tests when tools like the openssl cli are available. Curl is just an http client, unless they rolled their own, they're at the whims of whatever SSL impl was linked in. Go talk to a senior Linux sysadmin and ask for help you sad little web developer children. This is not a Mac problem, this is an every unix is different and welcome to the party problem.
There's something very karmic about Linux tossing aside decades of Unix standards and some kids getting upset that an http client doesn't do what Linux does, made me laugh.
Re: (Score:2)
And then... why is anyone using curl to do very specific SSL validation tests when tools like the openssl cli are available.
Because they are using curl for whatever reason they use curl (ease of its command line as compared to other https clients, or whatever).
And it only makes sense to do the validation along with the rest of the https access (which could be the submission of a form, which contains sensitive data).
The reason for this is twofold:
Re: (Score:3)
Curl is just an http client
Not quite. It is also an SMTP client, an FTP client, an MQTT client, an IMAP client, and a few other things I forget.
Ah, here, it reads in the manual:
It supports these protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS.
The point may not be to test SSL itself, but to test something that uses SSL.
Re: (Score:1)
Apple software quality is spirally down the bowl (Score:5, Informative)
I didn't know about Curl but the recent MacOS 14.4 release has broken the entire printing system - not just one or 2 specific printers, the entire system! I can't help thinking that even Microsoft might have noticed that before releasing a Windows update.
And when they're not breaking things the software they include is often pretty ancient - eg the version of the Clang C++ compiler shipped with macos still doesn't support C++20 properly - in 2024.
Their shipped version of Python3 is also a few years behind too.
Re: Apple software quality is spirally down the bo (Score:5, Informative)
They ship bash 3 because the licence changed with bash 4 to one they don't like. Hence with the switch the zsh too.
Handily homebrew gives me bash, so I'm happy.
Re: (Score:2)
I'm out of the loop on the bash 4 license change. What changed?
Thanks for the tip about homebrew still supporting bash.
Re: Apple software quality is spirally down the bo (Score:4, Informative)
GPL2 to GPL3.
Re: (Score:2)
GPLv3 is pure evil.
That's the perspective of freeloaders, yes.
Re: (Score:2)
GPLv3 is pure evil.
That's the perspective of freeloaders, yes.
Apple's hardly a F/OSS Leech, if that's what you're implying.
Re: (Score:2)
The switch to zsh was likely a confluence of the bash license change, and that zsh was the personally preferred shell of multiple members of the BSD team (er, before I left Apple, which was about 5 years before they changed the default shell, so maybe the entire BSD team turned over and I'm just indulging in wishful thinking). So you can blame me for introducing them to it ;-)
Re: Apple software quality is spirally down the bo (Score:5, Interesting)
CLI on macos seems janky overall, no matter how you use it, even if you ssh to a Linux box. I have problems with the macos terminal all the time, mainly surrounding the fact that it doesn't seem to update the screen reliably. I often will enter a command or type text and have nothing happen as a result, but the problem isn't the software, it's apple's shitty terminal. Microsoft's terminal within vs code does a way better job on mac than apple's own shit.
Re: Apple software quality is spirally down the bo (Score:5, Informative)
I don't have problems with screen updates in terminal, but cut and paste from other applications seems to be a random will-it-wont-it affair. Sometimes it works, sometimes it pastes an old buffer, sometimes it pastes nothing at all. Text cut and paste has been a solved problem for 40 years yet still Apple have managed to fuck it up.
Re: Apple software quality is spirally down the b (Score:2)
I've had that happen as well but I've generally dismissed it as perhaps me just hitting the wrong hotkey when I did the copy.
Re: (Score:2)
Nope, not you, its a bug - one of the many they can't seem to be bothered to fix.
Re: (Score:3)
Nope, not you, its a bug - one of the many they can't seem to be bothered to fix.
This is happening often enough to me lately that I was starting to think I was losing my mind. Glad it isn't just me and that macOS really does suck now.
Re: (Score:2)
I would look into whether you and others having these problems are running any specific software because I'm not seeing any of this weird behaviour.
Terminal, mostly.
Re: (Score:2)
Nope, not you, its a bug - one of the many they can't seem to be bothered to fix.
Interesting; since no doubt many Apple Devs. themselves obviously use it every single day as part of their job.
Re: (Score:2)
I use it every day as part of my job, but the main purpose is to ensure that my code actually runs on it. And because it's so god damn finicky to get monitors working correctly with it, I just leave it docked most of the time to avoid fighting that mess.
Re: (Score:1)
I thought Terminal was fine, but the osx "unix" userspace was always gratuitously and appallingly broken and/or out of date. It's like they pulled it all in to check a box, then let it rot while accumulating further breakage of their own making. Apple's refusal to fix the myriad bugs (not limited to command line utilities, and blindingly obvious to any more than casual user) was always infuriating. Each new release would come with hope that they'd fix something, and the inevitable disappointment that follo
Re: (Score:3)
eg the version of the Clang C++ compiler shipped with macos still doesn't support C++20 properly - in 2024
FFS, it still doesn't support OpenMP. You have to go find the equivalent version of LLVM, compile your own libomp, and then franken-link it in. It *seems* to work with AppleClang, but given possible divergence in both compiler branches, that's more of a happy coincidence than some sort of ironclad guarantee.
You *could* just use LLVM, but then you don't know if they made any other compatibility-breaking changes in AppleClang, esp. on their own CPU architecture.
Stallman was... right?
Re: (Score:2)
Re: (Score:2)
Stallman was "right" insofar that he is responsible for all of this.
Disagree... all of the compiler horse-shittery here is because Apple CHOOSES to ship their own ecclectic mix of llvm separate from the OSS versions available on other platforms. Like I said, it's not even clear there is a path to re-constituting all of the open-source components in LLVM to make your own copy of AppleClang (because they don't actually have to give you all of the bits in source-code form, much less a way to make your own equivalent binary). This is, of course, 100% their right to do (and th
Homebrew (Score:2)
Even for stuff that comes with MacOS I still use `brew install` to put a proper version in place 'cos the apple version always break something. I've just given up on them and put their stuff at the end of the PATH.
Re: (Score:2)
Re: (Score:2)
Apple'smotive in this specific case (Score:3)
What might Apple's motive be?
Re: (Score:2)
app store only and if you want side your own apps $0.50 per install / update!
Re: Apple'smotive in this specific case (Score:3)
Wouldn't be surprised if apple already sees brew as a competitor to the mac app store and a potential opportunity for revenue. Possibly jamf as well.
Re: (Score:2)
Re: (Score:1)
They probably use curl internally and are probably doing something silly with certificates, and they bandaided curl instead of using the tool properly, not thinking there might be security implications.
Re: (Score:2)
Apple's motive in this case is their cert system is intertwined with having securityd do as much of the work including in many cases policy enforcement as possible. That is a great tradeoff for their normal application stack, but doesn't intermesh well with the corners of how curl expects things to work. So they get a variant behaviour. Since curl isn't part of the "UNIX standard" (which Apple does care about complying with) anyone that gets the bug assigned to them can either work on it for a week and
Trusting Apple with Open Source (Score:3)
Basically trusting Apple to supply open source binaries is like trusting Microsoft to do it.
If you care, compile from sources. If you want to download uncurated binaries, start with Linux.
Re: (Score:2)
Basically trusting Apple to supply open source binaries is like trusting Microsoft to do it.
If you care, compile from sources. If you want to download uncurated binaries, start with Linux.
Ultimately the average person doesn't have the ability to audit all the code they use, hell most people with the capability don't have the time so we have to work on trust, FOSS tends to be the most trustworthy source.
However your first sentence is right, if anything Apple is less trustworthy with open source than Microsoft, in fact less trustworthy in general and I don't trust Microsoft as far as I can throw them.
Backdoor uses (Score:5, Interesting)
Basically to me this is a backdoor situation.
1. Attacker drops their own extra certs into the ca store.
2. They man in the middle your connection with their cert.
3. Your EXPLICIT request to use your cert gets IGNORED and the man in the middle goes undetected.
Re: Backdoor uses (Score:3)
If somebody has managed to surreptitiously drop their own certs in to the store, then youâ(TM)ve got bigger problems than them using it to MIT some HTTPS connections. Itâ(TM)s game over.
Re: Backdoor uses (Score:5, Interesting)
Of course but basically this is how a nation state level attacker would nail everyone. Dropping certs into the system store via some government mandated backdoor is feasible. It would silently allow compromise of hosts via the POISONNUT/XKEYSCORE infrastructure Snowden leaked existence of.
Re: (Score:2)
However, this curl backdoor allows a nation state level attacker to lean on a CA under its control, which happens to be already in the system CA store (but not in the user's own trimmed down CA store).
Re: (Score:2)
If somebody has managed to surreptitiously drop their own certs in to the store
That's a feature, not a bug. Any CA can insert their own certs that override other certs.
https://bugzilla.mozilla.org/s... [mozilla.org]
Re: (Score:2)
Also, in the case of OP's mention and the story, the -cacert flag is explicitly supposed to ignore the certificate store and force the cURL executable to evaluate only the certificate(s) asked. Apple's implementation is changed to always check the certificate store, which can defeat measures like certificate p
Re: (Score:2)
Honest Achmed's request is just as valid as that of any other CA. The business model is identical, and Achmed is more trustworthy than any company beholden to the NSA.
I agree that Apple broke the feature. That's not the point. The point is that certificate injection is a feature of the protocol. That's why pinned self-signed certificates are regarded as less secure than certs that are eminently replaceable by a third party. The Apple App Store doesn't even accept apps that use certificate pinning. If A
Re: (Score:3)
Re: (Score:2)
You're probably 99% correct, but Apple does make Windows software as well as needing to test interoperability with Windows systems, so there must be SOME PC clients on their internal network.
Re: (Score:2)
While it has been a decade since I worked at Apple, the CoreOS division had an institutional response to the IT team asking for anything. It was laughter. The security team within the CoreOS team doubly so, but only when they could stop laughing long enough to listen to the request first.
This isn't always healthy, it is part of why it took Apple so long to design a device managment system that made IT departments happy, because they never listen to their own it took much longer to figure out what IT dep
Re: (Score:2)
Re: (Score:2)
if the attacker can add to your CA store
That's exactly what Apple did here.
People Ask All the Time (Score:5, Insightful)
"Hey, why do you invest so much time and effort to run Linux?"
Simple answer:
"So I have control over my own machine."
"Why is that so important?"
"Because if I leave it up to someone else they'll FUCK IT UP and then blame me."
Re: (Score:2)
My answer would be that I don't.
Linux is the simpler, easier choice. Maybe the barrier to entry is you have to be generally good with computers but that's my day job anyway, regardless of the OS. Given that, Linux is for me very much the easy choice.
Actually here's an interesting talk which I think touches n that topic:
https://www.youtube.com/watch?... [youtube.com]
"NTFS isn't really that bad", which is a guy debugging glacial git performance on Windows, previously assumed to be the fault of NTFS. It's not, and a good d
I can see a reason to do this (Score:1)
Re: (Score:3)
Re: I can see a reason to do this (Score:2)
When Big Daddy trusts a certificate, you, as a mere user, can't distrust it. Choose a different way to do things, a different OS, or if everything else fails, a different work place.
Blackjack! And hookers! (Score:1)
There seems to be an obvious solution to anyone who finds themselves in this boat and needing to use MacOS for some reason: build their own stock version of curl and use that. Did someone mention homebrew?
Re: (Score:3)
Did someone mention homebrew?
Yes, the guy who filed the bug report. Because building curl from source through Homebrew will still link to Apple's own SSL library, which injects their own certs.
Re: (Score:1)
What about OpenSSL, is it available from homebrew? Sounds like it's time to build OpenSSL from source, and link curl to it.
Why Didn't They Modify the Version Num? (Score:5, Interesting)
Backdoors. Backdoors everywhere. (Score:3)
I wonder which dissidents' comms app depended on -cacert for internal security.
Re: (Score:2)
None. Using https and TLS does little to provide anonymity. Using cURL in such a scenario is little more than a straw man that simply isn't a plausible use case when we have vetted tools for dissidents like the Tor Browser Suite, Signal, and I'm sure others I'm less familiar with.
Sticking to your roots (Score:2)
Overriding the behavior of cURL like this is dangerous and should be treated as a security vulnerability.
Over the years we occasionally see some interesting things pop out of distributing trust anchors to clients. Every once in a while get complaints about failures caused by malware and "security" software that has installed its own roots into the OS cert store in order to MITM all of your traffic. I would say about a quarter of the time the customer was completely oblivious to what was going on.
Felony Wire Fraud/RICO? Or NSL Compliance? (Score:2)
Nevertheless, this only needs to combine with a hidden shim proxy to enable man-in-the-middle attacks, with susceptibility to wire fraud and content tampering.
Also, does the Mac manpage for curl disclose this modified effect of -cacert? If not, then the software is being fraudulently misrepresented.
And on a whole different note, is it possible Apple received a National Security Letter (NSL) c
Re: (Score:2)
Not only does the Mac manage disclose the behavior of -cacert, so does the Linux manage, and the manage on man7.org [man7.org], and curl.se [curl.se]
Additionally, the macOS CA keystores are easily searchable, verifiable, and modifiable. If you want to go to your system, remove all of the CA Certificates and verify that -cacert doesn't verify after deleting keys, you can do that.
You can also clone the source code Apple publishes for their fork of cURL [github.com] - which they do for every patch of macOS.
I dunno... part of me wonders if it's
Apples rep is wrong wrong wrong (Score:2)
There is the Microsoft way... (Score:2)
Microsoft just puts cURL in their system but doesn't bother to update it for months even when there are known vulnerabilities. For added measure, if you update it yourself chances are you'll break things. So you get the join of your security group screaming fix it as you just have to keep reminding them you can't. Then Microsoft eventually patches it and months down road after you get to repeat the whole situation again.
Business as usual (Score:1)
Apple is the new Microsoft (Internet Explorer). (Score:1)