Impact
Part of the server-side validation for uploading a new CocoaPod to the central repository of Podspecs (trunk) could be exploited to execute arbitrary shell commands on the trunk server.
We were contacted via Max Justicz this morning who provided us with a great technical write-up and showed how to trigger it for ourselves. The exploit is a combination of unsanitized user-input getting through to a git call param which can be used to send remote payloads.
You can read more on our blog post: https://blog.cocoapods.org/CocoaPods-Trunk-RCE/
Patched
This vulnerability was introduced on Jun 4th, 2015 and has been fixed as of 11am GMT April 19th 2021. There's nothing which CocoaPods users need to do.
As most git commit's in the Specs repo are automated through trunk, we have built some introspection tools to validate the Specs repo commits against the sort which have been created by publishing/deprecating/deleting through trunk. The majority of the other commits are around setting up infra for the CDN support, and CocoaPods release pushes.
How it worked
During the deploy of a podspec to trunk, the server validates that the repo is accessible to git. This is done to help fix potentially broken podspecs with typoes, local auth which won't work for others or external repos don't have tags already set up. This validation used to rely on using the git CLI on trunk using git ls-remote to replicate the same check as a user's git would, but ls-remotes has a parameter --upload-pack which can be used to execute a new shell.
This meant an attacker could create a specially crafted Podspec, which would trigger the upload-pack param and execute an arbitrary command on trunk.
Safeguards
We've not been able to prove that anyone has used this method before Max's report today. However, just because it hasn't been proved, doesn't mean it hasn't happened. 6 years is a long time. We have cycled all of the access tokens on trunk, and will be planning on cleaning out all pod trunk sessions as a safeguard very soon.
This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deploying to CocoaPods, this will break, and you will need to register again and replace your COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.
References
For more information
If you have any questions or comments about this advisory:
justicz Analyst
Impact
Part of the server-side validation for uploading a new CocoaPod to the central repository of Podspecs (trunk) could be exploited to execute arbitrary shell commands on the trunk server.
We were contacted via Max Justicz this morning who provided us with a great technical write-up and showed how to trigger it for ourselves. The exploit is a combination of unsanitized user-input getting through to a git call param which can be used to send remote payloads.
You can read more on our blog post: https://blog.cocoapods.org/CocoaPods-Trunk-RCE/
Patched
This vulnerability was introduced on Jun 4th, 2015 and has been fixed as of 11am GMT April 19th 2021. There's nothing which CocoaPods users need to do.
As most git commit's in the Specs repo are automated through trunk, we have built some introspection tools to validate the Specs repo commits against the sort which have been created by publishing/deprecating/deleting through trunk. The majority of the other commits are around setting up infra for the CDN support, and CocoaPods release pushes.
How it worked
During the deploy of a podspec to trunk, the server validates that the repo is accessible to git. This is done to help fix potentially broken podspecs with typoes, local auth which won't work for others or external repos don't have tags already set up. This validation used to rely on using the git CLI on trunk using
git ls-remoteto replicate the same check as a user's git would, butls-remoteshas a parameter--upload-packwhich can be used to execute a new shell.This meant an attacker could create a specially crafted Podspec, which would trigger the
upload-packparam and execute an arbitrary command on trunk.Safeguards
We've not been able to prove that anyone has used this method before Max's report today. However, just because it hasn't been proved, doesn't mean it hasn't happened. 6 years is a long time. We have cycled all of the access tokens on trunk, and will be planning on cleaning out all
pod trunksessions as a safeguard very soon.This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deploying to CocoaPods, this will break, and you will need to register again and replace your
COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.References
For more information
If you have any questions or comments about this advisory: