A remote code execution vulnerability identified on the central CocoaPods server could have allowed an attacker to poison any package download, security researcher Max Justicz reveals.
A dependency manager for Swift and Objective-C Cocoa projects, CocoaPods has more than 82,000 libraries and is being used in over 3 million applications. The tool is built using Ruby and can be used with the default Ruby on macOS.
The identified vulnerability, Justicz explains, resides in a function designed to check that, when a package spec was uploaded to CocoaPods, it was not linking to a private repository.
In short: the manner in which the function checked the contents of a flag could have allowed an attacker to serve tailored content and abuse it to run commands.
The vulnerability was disclosed to CocoaPods on Monday, and a patch was deployed server-side on the same day.
“The exploit is a combination of un-sanitized user input getting through to a git call param which can be used to send remote payloads,” CocoaPods developer Orta Therox explains.
Successful exploitation of the flaw, he notes, could lead to the execution of arbitrary shell commands on the server, thus allowing an attacker to read environment variables and write to the CocoaPods/Specs repo or even read the trunk database.
While the patch was deployed server-side and CocoaPods installations were not affected, developers would still need to log in to the central repository of Podspecs (trunk) again and deploy any new Podspecs.
The change also breaks automated deployments to CocoaPods and requires developers to replace their COCOAPODS_TRUNK_TOKEN. This, however, ensures that no one else has access to one’s pods.
The vulnerability was introduced in 2015 but, despite the long time during which the flaw resided on the server, the CocoaPods team doesn’t believe that the CocoaPods Specs repo has been tampered with. Furthermore, they say, there’s no proof that anyone has exploited the issue in the manner described by Justicz.
“However, just because it hasn’t been proved, doesn’t mean it hasn’t happened. 6 years is a long time. The worst case scenario is that an attacker could have used this technique to get access to our trunk database,” Therox notes.
While the trunk database contains email addresses that are already public, it also contains session keys, which could be used to allow unauthenticated users to connect to pods. Thus, CocoaPods is deleting all session keys, to prevent pod compromise.
“From the side of our investigation, we cannot automatically detect if someone has deployed a poisoned copy of a Pod,” Therox notes.
Related: Library Dependencies and the Open Source Supply Chain Nightmare
Related: Software Dependencies Exposed Microsoft, Apple to High-Impact Attacks
Related: GitHub Helps Developers Keep Dependencies Secure via Dependabot
