Comment by nightpool | Hacker News Reader

Comment by nightpool | Hacker News Reader

The article mentions that RubyGems is vulnerable to this, and that Shopify in particular downloaded and ran a gem named "shopify-cloud", but I'm curious as to how this is possible given a "normal" bundler pure-lockfile setup, or more generally the source-block directives I've seen in most Gemfiles.

That is, given a Gemfile.lock like, e.g.

    GIT
      remote: https://github.com/thoughtbot/appraisal
      revision: 5675d17a95cfe904cc4b19dfd3f1f4c6d54d3502
      specs:
        appraisal (2.1.0)
          bundler
          rake
          thor (>= 0.14.0)

How would Bundler ever try and download the `appraisal` gem from RubyGems?

The Gemfile section is more explicable. While newer Gemfiles look like this:

    source "http://our.own.gem.repo.com/the/path/to/it" do
      gem 'gemfromourrepo'
    end
    # or
    gem 'gemfromourrepo', source: "http://our.own.gem.repo.com/the/path/to/it"

Older Gemfiles apparently looked like the following:

    source 'https://rubygems.org'
    source 'http://our.own.gem.repo.com/the/path/to/it'

    gem 'gemfromrubygems1'  
    gem 'gemfromrubygems2'
    gem 'gemfromourrepo'

Which seems obviously vulnerable to the dependency confusion issue mentioned.

So is the understanding that Shopify's CI systems were running `bundle upgrade` or another non-lockfile operation? (possibly as a greenkeeper-like cron job?) Or is `--pure-lockfile` itself more subtly vulerable?

Someone will eventually update deps, not necessarily CI. But now that devs machine is compromised. The attacker probably only has a small window of time after it gets in, but it should be long enough to exfiltrate dot-files and the source code of whatever it gets included in. Now they have ssh keys (mine are on a yubikey), and the GitHub url. They can further push malicious code into the repo.

I would hope most SSH keys are password-encrypted if not protected by a hardware token like yours, but I agree that the "unscoped-source" Gemfile syntax is a huge vulnerable hole, and a bad one. I'm just confused about how what seems like a pretty uncommon operation led to such an immediate response and code execution from Shopify.

(I also don't think it's true that the attacker has a "small window of time"—as soon as they get a single RCE, it's over, if they're running on a normal dev machine then they can daemonize into the background, add persistence, and snoop events over time. CI systems are obviously less vulnerable to this by nature.)

Note that at least on Linux, deploying a keylogger to exfiltrate the password for a SSH key is not hard either. Even if a keylogger is somehow not possible, you can probably still replace key binaries with patched versions or change desktop shortcuts to launch modified programs.

It’s a small window because it’s going to take about 20-30 mins for the dev to figure out why tests failed, locate the bogus dependency and shut down their computer, notify secops, revoke keys (if they even think of that), etc.

If you know your computer was compromised. Shut down and reinstall from a backup, you don’t try and clean it.

Edit: I’m assuming the attacker would be replacing a dependency with an empty repo since they don’t know the actual source code. If they know the interface the dependency is supposed to provide, it could spread across the entire organization before anyone noticed.

> I would hope most SSH keys are password-encrypted

TBH, these are probably weak passwords for convenience.

If I'm reading bundler's docs rightly, the new 'source' syntax only appears to prevent this: https://bundler.io/man/gemfile.5.html#SOURCE-PRIORITY

I don't think this is correct—I read the earlier section of the docs ("Block Form Of Source, Git, Path, Group And Platforms") as saying that the block form is equivalent to the "source explicitly attached to the gem", the first priority item in your link

However, this section is concerning:

> The presence of a source block in a Gemfile also makes that source available as a possible global source for any other gems which do not specify explicit sources. Thus, when defining source blocks, it is recommended that you also ensure all other gems in the Gemfile are using explicit sources, either via source blocks or :source directives on individual gems.

Yikes! This is yet another easy footgun for people to reintroduce this issue

Reply on news.ycombinator.com