New CocoaPods CVEs: Swift and Objective-C Supply Chains Are Fragile
Three CocoaPods CVEs raise serious security concerns for consumers of Swift and Objective-C libraries used for macOS and iOS mobile development.
Three CocoaPods CVEs raise serious security concerns for consumers of Swift and Objective-C libraries used for macOS and iOS mobile development.
Three CocoaPods CVEs raise serious security concerns for consumers of Swift and Objective-C libraries used for macOS and iOS mobile development.
Three CocoaPods CVEs raise serious security concerns for consumers of Swift and Objective-C libraries used for macOS and iOS mobile development.
Three CocoaPods CVEs raise serious security concerns for consumers of Swift and Objective-C libraries used for macOS and iOS mobile development.
Three newly-reported vulnerabilities raise serious concerns about the safety of Swift and Objective-C libraries used for macOS and iOS mobile development
CocoaPods is an extremely well-known package manager and repository for open source software libraries (which they call Pods, not to be confused with Kubernetes pods) for the Objective-C and Swift programming languages that many macOS and iOS applications are written in. Even with Swift, the more recent of the two languages, having its own package manager (SPM) and package repository (Swift Package Index, or SPI), CocoaPods remains a significant and widely-used part of the development ecosystem for Apple’s operating systems.
So when E.V.A Information Security discovered three vulnerabilities in the Trunk server that runs the whole CocoaPods repository, it rightly caused significant concern. The good news is that these problems have been patched by CocoaPods prior to the disclosure. The bad news is that no one really knows if adversaries took advantage of these vulnerabilities — if they did, there could be a significant software supply chain attack still affecting Pods users.
E.V.A’s writeup has excellent technical detail on the vulnerabilities, but here’s a quick rundown of what they are and what to do now.
Adversaries Can Take Over Unclaimed Pods: CVE-2024-38368
Due to a design flaw, the CocoaPods server allows any CocoaPods user to claim a Pod that doesn’t have an identified owner, without any verification. This means an adversary can register a CocoaPods account and claim a Pod. This allows them to distribute malware as if they were a trusted maintainer (see: [AV-504] Distribute As Package Maintainer).
How does CVE-2024-38368 impact me?
This CVE doesn’t impact you directly, but if it was ever exploited (which we don’t know yet), then that could have a big impact to your supply chain for Swift and Objective-C applications. To determine if you’ve potentially been impacted, you can examine the Pod’s ownership to determine if there was a recent change. This is, unfortunately, somewhat resource-intensive. CocoaPods does not provide easy access to ownership history data, so unless you or one of your tools has been monitoring this, all you’ll have to go by is “when did ownership change?” Since this vulnerability likely existed since May 2014, even though it was just discovered and reported in 2024, that’s a big potential list. This is not a fun time for defenders! We simply don’t know if adversaries discovered and used this vulnerability, and if so, how widespread the issue might be.
Adversaries Can Bypass Email Validation And Take Over Legitimate CocoaPods Accounts: CVE-2024-38367
E.V.A lists this CVE last in their report, but it’s a similar attack vector as the above, with a similar result for Pods consumers. This vulnerability results from the CocoaPods server trusting a request header it shouldn’t. The end result is that the email validation workflow -- the thing that requires that a CocoaPods user validate that they control a newly-provided email address, to prevent account takeovers -- can be entirely subverted by an adversary. Once they have taken over the account, they can proceed, as above, to replace a Pod with a malicious or compromised version.
How does CVE-2024-38367 impact me?
As a defender, your response is the same as above — check to see if owner data has recently changed, and examine current versions to determine if there are potentially malicious instructions. Again, the bad news for defenders is that “recent” is “possibly up to 10 years ago”.
Adversaries Can Execute Code On The CocoaPods Servers: CVE-2024-38366
Due to a flaw in a Ruby gem called ‘rfc-822’, (an open source library on which the CocoaPods server software depends in order to validate email addresses) adversaries can provide inputs to “email address” fields that cause the CocoaPods server to run programs and shell code that the adversary chooses. The package name (rfc-822) is a reference to the IETF document RFC-822 which defined Internet mail formats, including the format of email addresses that we use today.
How does CVE-2024-38366 impact me?
While this vulnerability, like the others, is primarily of concern for the CocoaPods organization, other defenders do have two considerations:
- As with the other vulnerabilities, this vulnerability could be used as an attack vector for supply chain attacks ([AV-700] Compromise System); however, indicators of compromise are more difficult for defenders to obtain.
- If you, as a defender, are using the rfc-822 Ruby gem, you will want to know about it because you might need to mitigate this Remote Code Execution vulnerability in your software. As of this writing, you can’t rely on your alerting systems to warn you, as this CVE is not currently associated with the rfc-822 package directly.
For the second case, you should also examine SBOMs (Software Bills of Materials) for your 3rd-party software to determine if any of your vendors are potentially including this vulnerable library in their products.
Software Supply Chain Security Is A Team Sport
When there are serious software supply chain security (SSCS) issues like this, it’s easy to point a finger at the volunteers who build and maintain these critical package repositories. But SSCS issues affect everyone, and defense is therefore everyone’s job. Supporting important projects like the CocoaPods repository, not only to ensure continuity of service but also to make sure the volunteer teams have the resources needed to stay on top of security, is an important part of this.
But it’s also a good reminder to take responsibility for our own part in the SSCS game:
- Have people, processes, and tools (like Endor Labs) that maintain an accurate software inventory (including your OSS dependencies), so you can respond quickly to reported risks.
- Continuously monitor for supply chain risks beyond just “CVEs in libraries” and “unapproved licenses”; use the OWASP Top 10 OSS Risks as a guide.
- Implement a comprehensive package monitoring system to help guide initial selection of OSS dependencies. (see example below)
- Distribute and consume SBOM and VEX documents, as appropriate, to manage the parts of your supply chain that don’t get scanned by software composition analysis (SCA) and other inventory tools.
And of course, pay attention to offensive security reports resulting from the excellent and responsible research and disclosure work from places like E.V.A, as part of a broader threat and risk intelligence program.
