3 ms·

The current title is "Rubygems.org compromised." Isn't this just a gem that exploits the YAML bug, not an exploit on RubyGems.org? I believe this submission nee

The current title is "Rubygems.org compromised." Isn't this just a gem that exploits the YAML bug, not an exploit on RubyGems.org? I believe this submission needs a title change. Edit: I am incorrect. It seems that this uploaded gem was used to compromise RubyGems.org.

veloper 14y ago
I think you're right, the title is inaccurate. Running `$ bundle update` will not inject this into your app. You'd have to intentionally add `gem "exploit", "~> 22.31.31"` to your Gemfile.
- kawsper 14y ago
  Couldn't all gems fetched from Rubygems be infected?
  - timdorr 14y ago
    Yes, but the attacker would need to inject code into every .gem file that's pushed to rubygems.org. Because that source code would be highly visible, it would be simple to figure out what they're trying to do. A more hidden attempt would be to simply alter the existing .gem files on S3. Once they have the access tokens from the configuration YAML files, they can do that from anywhere, not just the rubygems.org host. That keeps their activity under the radar and is slightly harder to track. In that case, only newly installed gems in your system that were uploaded to rubygems.org before this incident would be at risk. If you run bundle update and pull in gems built from today onward, there is not as much to worry about. If you're updating gems and the bundle is pulling in gems from a few days ago, then you are at high risk.
    - nirvdrum 14y ago
      I'm not disputing anything here, but I just want to emphasize that if they have the S3 credentials, replacing any gem is trivial. And they wouldn't need to replace every gem. Picking the 10 most popular ones would have pretty big fallout. And, if like most people you don't verify your installed gems (not that you really can if they're not signed), you're going to have a very bad day. The "tracking" aspect is a situation where it doesn't matter because at that point, you're hosed anyway. Also, walking S3 is not particularly fast. So if the plan is to walk all gem files to verify them, expect that to take a while. Hopefully they have bucket logging enabled.
benmmurphy 14y ago
it looks like someone has tried to steal rubygems.org db and other credentials. bundle update is now dangerous because you might get trojaned files.
- benmanns 14y ago
  But don't applications have to explicitly install this gem? If not, then I am incorrect.
  - bradleyland 14y ago
    We don't know the extent to which Rubygems was compromised yet. In a scenario like this, it's best to err on the safe side and avoid trusting the source for the time being.
  - bittersweet 14y ago
    Qrush, one of the guys behind Rubygems tweeted that the credentials of every yml file ended up on pastie: https://twitter.com/qrush/status/296638346283868160 https://twitter.com/qrush/status/296638346283868160 > Someone posted http://rubygems.org http://rubygems.org 's config/*.yml to pastie. Didn't include the S3 bucket secret key, but going to reset everything anyway.

veloper 14y ago

I think you're right, the title is inaccurate. Running `$ bundle update` will not inject this into your app. You'd have to intentionally add `gem "exploit", "~> 22.31.31"` to your Gemfile.

kawsper 14y ago
Couldn't all gems fetched from Rubygems be infected?
- timdorr 14y ago
  Yes, but the attacker would need to inject code into every .gem file that's pushed to rubygems.org. Because that source code would be highly visible, it would be simple to figure out what they're trying to do. A more hidden attempt would be to simply alter the existing .gem files on S3. Once they have the access tokens from the configuration YAML files, they can do that from anywhere, not just the rubygems.org host. That keeps their activity under the radar and is slightly harder to track. In that case, only newly installed gems in your system that were uploaded to rubygems.org before this incident would be at risk. If you run bundle update and pull in gems built from today onward, there is not as much to worry about. If you're updating gems and the bundle is pulling in gems from a few days ago, then you are at high risk.
  - nirvdrum 14y ago
    I'm not disputing anything here, but I just want to emphasize that if they have the S3 credentials, replacing any gem is trivial. And they wouldn't need to replace every gem. Picking the 10 most popular ones would have pretty big fallout. And, if like most people you don't verify your installed gems (not that you really can if they're not signed), you're going to have a very bad day. The "tracking" aspect is a situation where it doesn't matter because at that point, you're hosed anyway. Also, walking S3 is not particularly fast. So if the plan is to walk all gem files to verify them, expect that to take a while. Hopefully they have bucket logging enabled.

benmmurphy 14y ago

it looks like someone has tried to steal rubygems.org db and other credentials. bundle update is now dangerous because you might get trojaned files.

benmanns 14y ago
But don't applications have to explicitly install this gem? If not, then I am incorrect.
- bradleyland 14y ago
  We don't know the extent to which Rubygems was compromised yet. In a scenario like this, it's best to err on the safe side and avoid trusting the source for the time being.
- bittersweet 14y ago
  Qrush, one of the guys behind Rubygems tweeted that the credentials of every yml file ended up on pastie: https://twitter.com/qrush/status/296638346283868160 https://twitter.com/qrush/status/296638346283868160 > Someone posted http://rubygems.org http://rubygems.org 's config/*.yml to pastie. Didn't include the S3 bucket secret key, but going to reset everything anyway.