9 ms·

Remote Code Execution Found in CocoaPods

220 points by st3fan 6y ago

deleted 6y ago
[deleted]
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
ChrisMarshallNY 6y ago
Kudos to them for a proactive approach. I'm deprecating my use of Cocoapods (for publishing -I never use them for my own software), in favor of SPM. That said, it's clearly a labor of love, and filled an important niche for years.
- zacwest 6y ago
  SPM has a lot of issues, though. For example: if you depend on a static library, it will both statically link it _and_ embed the binary; likewise, a static library dependency in a framework will cause build failures ~70% of the time when clean. There's others around resources, etc. I do not believe SPM is mature enough to be the entire platform, and worst yet if you experience any problems it is entirely impossible to customize the behavior. I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries -- SPM works for the most basic use cases, but not all.
  - tspike 6y ago
    Carthage has been a happy middle ground for us. It doesn't dictate the structure or configuration of your project.
    - lyptt 6y ago
      Only annoyance for me with Carthage is needing to strip architectures out of the built frameworks in order for the app to be validated when uploading to App Store Connect. It's an awesome solution though, and much better than CocoaPods.
      - AJRF 6y ago
        Carthage supports XCFrameworks now which means this is no longer required.
        lyptt 6y ago
        Nice! Glad to hear that's finally been fixed
  - AJRF 6y ago
    > if you depend on a static library, it will both statically link it _and_ embed the binary That's fixed in Xcode 12.5 https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
    - ChrisMarshallNY 6y ago
      Ah. I see why this has not been an issue with me for most (maybe not all) of my projects. Most have only a single-layer dependency. Looks like this happens for chained dependencies ("a Swift package with binary dependencies", below), in apps with extensions (I have none). This is from the 12.4 notes[0]: > If you use a Swift package with binary dependencies in an app with extensions, the build system incorrectly embeds the binary dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306) Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/.framework.* I do not see a note in the 12.5 notes addressing this[1]. [0] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages https://developer.apple.com/documentation/xcode-release-note... [1] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
      - AJRF 6y ago
        Do you know the difference between dynamic and embedded binaries?
        ChrisMarshallNY 6y ago
        Any particular reason for the insult? I don't remember saying anything bad about you. Maybe, we could have found more in common than you may think. We both seem to be passionate about the same kind of stuff. I was under the impression that we should make an effort to be a wee bit more respectful with each other, than we might in venues like Reddit or SO (where they have the "digital sneer" down to a science). That was the only thing I could find that mentioned anything like it at all. I checked my builds every which way from Sunday, and I never had a double-embedded static lib. I was wondering if they may have been mixed up. Otherwise, there's nothing at all about it. I pretty much always use static libs, but sometimes, I may need a .framework. I've been using SPM for months, and have published a bunch of libs. I do tend to be conservative, and reduce the surface of dependencies wherever possible. I eat my own dog food, and am the only consumer (that I know of) of my packages. My chains tend to be short.
  - danpalmer 6y ago
    > I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries For libraries this is probably true, but I would imagine that most apps could start on SPM from today and never need to introduce CocoaPods or Carthage (we did, ~1 year ago). There are certainly limitations, but they are disappearing fairly rapidly, and the advantage of simpler builds, no Ruby setup, simpler Xcode project structures, etc, are worthwhile.
  - ChrisMarshallNY 6y ago
    Well, I won't go into the issues that prevent me from using CocoaPods, and why I'm not going to be publishing my libraries on them, from now on, but SPM has worked well for me. I am very careful about what I include in my projects. Most of my dependencies are fairly small ones that I wrote and published. Many are a single source file. I don't see the libraries being embedded in my project, but maybe I need to use something like iMazing to look at the package.
justicz 6y ago
I found this bug! Here's my blog post about it: https://justi.cz/security/2021/04/20/cocoapods-rce.html https://justi.cz/security/2021/04/20/cocoapods-rce.html I started looking because I wanted to find bugs in Signal for iOS, which uses CocoaPods: https://github.com/signalapp/Signal-iOS/blob/master/Podfile https://github.com/signalapp/Signal-iOS/blob/master/Podfile
- sigg3 6y ago
  I like your shameless plug: > I’m trying to give 10,000 mosquito nets to charity! If you liked this post please consider donating a $2 mosquito net. https://giveanet.org/ https://giveanet.org/
  - dgs_sgd 6y ago
    That's not a shameless plug, just a plug.
    - asddubs 6y ago
      by definition, any plug done without shame is shameless
  - spondyl 6y ago
    Didn't Bill Gates purchase a heap of malaria nets only for it to turn that out that people were using them for things like fishing and generally just not using them for their intended purposes? Not to diminish the finding mind you, just that I was surprised to hear about malaria nets. https://www.nytimes.com/2015/01/25/world/africa/mosquito-nets-for-malaria-spawn-new-epidemic-overfishing.html https://www.nytimes.com/2015/01/25/world/africa/mosquito-net...
    - tclancy 6y ago
      So you're saying the world got better because of it? Why is everything some Benthamite calculus?
SiempreViernes 6y ago
Honestly surprised this wasn't about some internet connected coffee machine! I expect you could make a hard developer trivia game where people have to guess if a vulnerability was found in an IOT app or a SAAS app based only on the name.
- amelius 6y ago
  > Honestly surprised this wasn't about some internet connected coffee machine! Whenever IT folks run out of good names they always turn to coffee.
- hashmush 6y ago
  Like this one? Not IoT or SaaS, but big data. https://pixelastic.github.io/pokemonorbigdata/ https://pixelastic.github.io/pokemonorbigdata/
AJRF 6y ago
Looks like they've made an web-app (https://pod-sources.cocoapods.org/ https://pod-sources.cocoapods.org/) to check the distinct sources of a pod so you can have a fish to see if a source location url changed behind your back. Would be good to show a list of all repositories where there are more than 1 distinct source as most people who make pods just point to their Github repo release page. It's very tedious to check the impact of this without that list.
- algoma 6y ago
  It would be possible to do this by querying the specs repo https://github.com/CocoaPods/cdn.cocoapods.org https://github.com/CocoaPods/cdn.cocoapods.org. This is what the web-app does. I noticed that quite a few pods have more than 1 distinct source when checking the pods used by projects I have worked on. From what I could see source changes were the result of ownership changes, GitHub account name changes, etc. So i'm not sure how to distinguish malicious source changes from innocuous ones. Maybe it would be worthwhile to search for source changes that lasted a single release and reverted thereafter.
QuercusMax 6y ago
There's a typo in the title; Should be CocoaPods, not Cococa.
- dang 6y ago
  Fixed now. Thanks!
deleted 6y ago
[deleted]
mcraiha 6y ago
We only need CocoaPods, because Apple couldn't build a proper package manager for XCode. And I am quite sure event Apple uses CocoaPods internally. CocoaPods itself is quite problematic: You need Ruby to run it. Definitions aren't strict enough (you can use too old CocoaPods binary for package that doesn't support it). Pods can cause build conflicts/issues that might only be visible when you run your app.
- danpalmer 6y ago
  I think the success and rapid adoption of Swift Package Manager as it has become a viable solution speaks to this deep desire in the community to have an Apple provided solution to it. CocoaPods was a hugely important part of the iOS ecosystem and will be for years to come, but SPM is a great next step.
  - Duckton 6y ago
    I think you overestimate how long CocoaPods will be used, all third party libraries I’ve used in the last 6-12 months supports SPM
    - throw14082020 6y ago
      Pseudo-counter point: SPM for firebase iOS SDK is in beta, and was released 2 weeks ago. Before this, you couldn't use SPM. The readme recommended (defaulted) to Cocoapods, with "experimental instructions for carthage". Therefore Cocoapods is likely used by most iOS apps with firebase.
    - username_my1 6y ago
      Our app is in objC and we’re not planning a rewrite anytime soon.
    - RandallBrown 6y ago
      And none of the ones I use support SPM.
      - 6y ago
deleted 6y ago
[deleted]
xucheng 6y ago
This seems to be an issue of git. It's very surprising that a git command would invoke its arguments in shell.
- tantalor 6y ago
  The issue is ruby's `system` method which interprets args in the shell. They should have used `popen` instead. This is similar to python's subprocess with `shell=True` Edit: I'm wrong! > ls-remote has a parameter --upload-pack which can be used to execute a new shell
  - xucheng 6y ago
    I don't believe this is the case. [1] pry(main)> system "echo", "$(whoami)" $(whoami) => true [2] pry(main)> system "git", "ls-remote", "--upload-pack=$(whoami)", "HEAD" $(whoami) 'HEAD': USERNAME: command not found fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. => false
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - tantalor 6y ago
      Oh, that's very silly. Don't do that!
      - xucheng 6y ago
        I think I understand why this happens. See https://news.ycombinator.com/item?id=26885103 https://news.ycombinator.com/item?id=26885103
    - kirby88 6y ago
      I had the same reaction as you... it looks like the vulnerability is coming from git, that's a very dangerous behavior.
w0mbat 6y ago
I don't use CocoaPods because a) they are a gaping supply chain vulnerability and b) they lead to bloat as people routinely pull in a whole package for one routine. I manually import and rewrite snippets of 3rd party code when needed, or I write needed utils myself. I lean on the OS as much as possible, not dodgy and often abandoned 3rd party libraries.
- eddieh 6y ago
  This is an underappreciated approach in modern developer culture.
pabs3 6y ago
Before passing attacker controlled variables to commands, always end option processing with the -- option! https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt https://www.defensecode.com/public/DefenseCode_Unix_WildCard...

220 points by st3fan 6y ago

deleted 6y ago

[deleted]

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

ChrisMarshallNY 6y ago

Kudos to them for a proactive approach. I'm deprecating my use of Cocoapods (for publishing -I never use them for my own software), in favor of SPM. That said, it's clearly a labor of love, and filled an important niche for years.

zacwest 6y ago
SPM has a lot of issues, though. For example: if you depend on a static library, it will both statically link it _and_ embed the binary; likewise, a static library dependency in a framework will cause build failures ~70% of the time when clean. There's others around resources, etc. I do not believe SPM is mature enough to be the entire platform, and worst yet if you experience any problems it is entirely impossible to customize the behavior. I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries -- SPM works for the most basic use cases, but not all.
- tspike 6y ago
  Carthage has been a happy middle ground for us. It doesn't dictate the structure or configuration of your project.
  - lyptt 6y ago
    Only annoyance for me with Carthage is needing to strip architectures out of the built frameworks in order for the app to be validated when uploading to App Store Connect. It's an awesome solution though, and much better than CocoaPods.
    - AJRF 6y ago
      Carthage supports XCFrameworks now which means this is no longer required.
      - lyptt 6y ago
        Nice! Glad to hear that's finally been fixed
- AJRF 6y ago
  > if you depend on a static library, it will both statically link it _and_ embed the binary That's fixed in Xcode 12.5 https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
  - ChrisMarshallNY 6y ago
    Ah. I see why this has not been an issue with me for most (maybe not all) of my projects. Most have only a single-layer dependency. Looks like this happens for chained dependencies ("a Swift package with binary dependencies", below), in apps with extensions (I have none). This is from the 12.4 notes[0]: > If you use a Swift package with binary dependencies in an app with extensions, the build system incorrectly embeds the binary dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306) Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/.framework.* I do not see a note in the 12.5 notes addressing this[1]. [0] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages https://developer.apple.com/documentation/xcode-release-note... [1] https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes https://developer.apple.com/documentation/xcode-release-note...
    - AJRF 6y ago
      Do you know the difference between dynamic and embedded binaries?
      - ChrisMarshallNY 6y ago
        Any particular reason for the insult? I don't remember saying anything bad about you. Maybe, we could have found more in common than you may think. We both seem to be passionate about the same kind of stuff. I was under the impression that we should make an effort to be a wee bit more respectful with each other, than we might in venues like Reddit or SO (where they have the "digital sneer" down to a science). That was the only thing I could find that mentioned anything like it at all. I checked my builds every which way from Sunday, and I never had a double-embedded static lib. I was wondering if they may have been mixed up. Otherwise, there's nothing at all about it. I pretty much always use static libs, but sometimes, I may need a .framework. I've been using SPM for months, and have published a bunch of libs. I do tend to be conservative, and reduce the surface of dependencies wherever possible. I eat my own dog food, and am the only consumer (that I know of) of my packages. My chains tend to be short.
- danpalmer 6y ago
  > I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries For libraries this is probably true, but I would imagine that most apps could start on SPM from today and never need to introduce CocoaPods or Carthage (we did, ~1 year ago). There are certainly limitations, but they are disappearing fairly rapidly, and the advantage of simpler builds, no Ruby setup, simpler Xcode project structures, etc, are worthwhile.
- ChrisMarshallNY 6y ago
  Well, I won't go into the issues that prevent me from using CocoaPods, and why I'm not going to be publishing my libraries on them, from now on, but SPM has worked well for me. I am very careful about what I include in my projects. Most of my dependencies are fairly small ones that I wrote and published. Many are a single source file. I don't see the libraries being embedded in my project, but maybe I need to use something like iMazing to look at the package.

justicz 6y ago

I found this bug! Here's my blog post about it: https://justi.cz/security/2021/04/20/cocoapods-rce.html https://justi.cz/security/2021/04/20/cocoapods-rce.html I started looking because I wanted to find bugs in Signal for iOS, which uses CocoaPods: https://github.com/signalapp/Signal-iOS/blob/master/Podfile https://github.com/signalapp/Signal-iOS/blob/master/Podfile

sigg3 6y ago
I like your shameless plug: > I’m trying to give 10,000 mosquito nets to charity! If you liked this post please consider donating a $2 mosquito net. https://giveanet.org/ https://giveanet.org/
- dgs_sgd 6y ago
  That's not a shameless plug, just a plug.
  - asddubs 6y ago
    by definition, any plug done without shame is shameless
- spondyl 6y ago
  Didn't Bill Gates purchase a heap of malaria nets only for it to turn that out that people were using them for things like fishing and generally just not using them for their intended purposes? Not to diminish the finding mind you, just that I was surprised to hear about malaria nets. https://www.nytimes.com/2015/01/25/world/africa/mosquito-nets-for-malaria-spawn-new-epidemic-overfishing.html https://www.nytimes.com/2015/01/25/world/africa/mosquito-net...
  - tclancy 6y ago
    So you're saying the world got better because of it? Why is everything some Benthamite calculus?

SiempreViernes 6y ago

Honestly surprised this wasn't about some internet connected coffee machine! I expect you could make a hard developer trivia game where people have to guess if a vulnerability was found in an IOT app or a SAAS app based only on the name.

amelius 6y ago
> Honestly surprised this wasn't about some internet connected coffee machine! Whenever IT folks run out of good names they always turn to coffee.
hashmush 6y ago
Like this one? Not IoT or SaaS, but big data. https://pixelastic.github.io/pokemonorbigdata/ https://pixelastic.github.io/pokemonorbigdata/

AJRF 6y ago

Looks like they've made an web-app (https://pod-sources.cocoapods.org/ https://pod-sources.cocoapods.org/) to check the distinct sources of a pod so you can have a fish to see if a source location url changed behind your back. Would be good to show a list of all repositories where there are more than 1 distinct source as most people who make pods just point to their Github repo release page. It's very tedious to check the impact of this without that list.

algoma 6y ago
It would be possible to do this by querying the specs repo https://github.com/CocoaPods/cdn.cocoapods.org https://github.com/CocoaPods/cdn.cocoapods.org. This is what the web-app does. I noticed that quite a few pods have more than 1 distinct source when checking the pods used by projects I have worked on. From what I could see source changes were the result of ownership changes, GitHub account name changes, etc. So i'm not sure how to distinguish malicious source changes from innocuous ones. Maybe it would be worthwhile to search for source changes that lasted a single release and reverted thereafter.

QuercusMax 6y ago

There's a typo in the title; Should be CocoaPods, not Cococa.

dang 6y ago
Fixed now. Thanks!

deleted 6y ago

[deleted]

mcraiha 6y ago

We only need CocoaPods, because Apple couldn't build a proper package manager for XCode. And I am quite sure event Apple uses CocoaPods internally. CocoaPods itself is quite problematic: You need Ruby to run it. Definitions aren't strict enough (you can use too old CocoaPods binary for package that doesn't support it). Pods can cause build conflicts/issues that might only be visible when you run your app.

danpalmer 6y ago
I think the success and rapid adoption of Swift Package Manager as it has become a viable solution speaks to this deep desire in the community to have an Apple provided solution to it. CocoaPods was a hugely important part of the iOS ecosystem and will be for years to come, but SPM is a great next step.
- Duckton 6y ago
  I think you overestimate how long CocoaPods will be used, all third party libraries I’ve used in the last 6-12 months supports SPM
  - throw14082020 6y ago
    Pseudo-counter point: SPM for firebase iOS SDK is in beta, and was released 2 weeks ago. Before this, you couldn't use SPM. The readme recommended (defaulted) to Cocoapods, with "experimental instructions for carthage". Therefore Cocoapods is likely used by most iOS apps with firebase.
  - username_my1 6y ago
    Our app is in objC and we’re not planning a rewrite anytime soon.
  - RandallBrown 6y ago
    And none of the ones I use support SPM.
    - 6y ago

deleted 6y ago

[deleted]

xucheng 6y ago

This seems to be an issue of git. It's very surprising that a git command would invoke its arguments in shell.

tantalor 6y ago
The issue is ruby's `system` method which interprets args in the shell. They should have used `popen` instead. This is similar to python's subprocess with `shell=True` Edit: I'm wrong! > ls-remote has a parameter --upload-pack which can be used to execute a new shell
- xucheng 6y ago
  I don't believe this is the case. [1] pry(main)> system "echo", "$(whoami)" $(whoami) => true [2] pry(main)> system "git", "ls-remote", "--upload-pack=$(whoami)", "HEAD" $(whoami) 'HEAD': USERNAME: command not found fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. => false
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - tantalor 6y ago
    Oh, that's very silly. Don't do that!
    - xucheng 6y ago
      I think I understand why this happens. See https://news.ycombinator.com/item?id=26885103 https://news.ycombinator.com/item?id=26885103
  - kirby88 6y ago
    I had the same reaction as you... it looks like the vulnerability is coming from git, that's a very dangerous behavior.

w0mbat 6y ago

I don't use CocoaPods because a) they are a gaping supply chain vulnerability and b) they lead to bloat as people routinely pull in a whole package for one routine. I manually import and rewrite snippets of 3rd party code when needed, or I write needed utils myself. I lean on the OS as much as possible, not dodgy and often abandoned 3rd party libraries.

eddieh 6y ago
This is an underappreciated approach in modern developer culture.

pabs3 6y ago

Before passing attacker controlled variables to commands, always end option processing with the -- option! https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt https://www.defensecode.com/public/DefenseCode_Unix_WildCard...