Home Security CocoaPods RCE Vulnerability Could Risk 3 Million Mobile Apps

CocoaPods RCE Vulnerability Could Risk 3 Million Mobile Apps

by

A serious remote code execution flaw affected the CocoaPods package manager that could have risked millions of apps. The vulnerability existed in the CocoaPods server for several years before it received a fix recently.

CocoaPods RCE Vulnerability Affected Millions Of Apps

Security researcher Max Justicz has recently shared his findings of a serious vulnerability affecting the CocoaPods server.

CocoaPods is an app-level dependency manager built with Ruby. It facilitates in managing external libraries by providing a standard format.

According to Justicz, the vulnerability specifically existed in the CocoaPods servers. Thus, it potentially impacted roughly 3 million different applications that rely on CocoaPods. These apps include some popular names like the Signal (iOS app) too.

Briefly, the researcher found this bug when he initially intended to test the Signal app but later decided to assess CocoaPods. That’s when he caught the bug that allowed remote code execution attacks on the CocoaPods server having keys for the Trunk (specs repo).

Explaining the exact issue, Justicz stated in his blog post,

 When you upload a package spec to CocoaPods, it tries to make sure you didn’t accidentally link to a private repository…
There are a couple of issues here. The most important one is the attacker has complete control over @specification.source[:git] and ref.to_s, and so can use them to pass flags to gitgit ls-remote takes an optional flag --upload-pack which happens to evaluate its contents in a shell. So if @specification.source[:git] is equal to something like --ls-remote="$(echo THIS WAS PROBABLY UNEXPECTED)" github.com, and ref.to_s is interpreted as a local repository, we’ll run the attacker’s command on the CocoaPods server.

CocoaPods Addressed The Flaw

Shortly after discovering the bug, the researcher reached to CocoaPods who then acted swiftly to patch the flaw.

Acknowledging the bug in a blog post, Orta Therox, the maintainer of CocoaPods, confirmed the fix. However, he also clarified that users may have to log in to Trunk again.

you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deployment to CocoaPods working right now, this will break, and you will need to pod trunk 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.

Although, the bug swiftly received a patch, and that Therox assured to have found no evidence of its exploitation.

Nonetheless, he explained that the bug existed for the past six years – first appearing on June 4, 2015. Therefore, the probabilities of malicious exploitation of the flaw do exist.

To prevent such issues in the future, Justicz advises dependency manager users to “consider vendoring dependencies”.

Whereas, he suggests the writers of dependency managers “treat” package contents and version control software as “toxic waste”. They should either avoid exposing this data or use a sandbox, like gVisor, if that’s, at all, necessary.

Source link

Related Articles

Leave a Comment