8 ms·

>> "a vulnerability in the gem installer that allowed a malicious gem to overwrite arbitrary files" Yeeks. Not good. (sudo) gem update --system ASAP

devmunchies 9y ago
would you have to go out of your way to find a malicious gem though? Its not like any of the popular gems would try to overwrite files, right?
- fish_fan 9y ago
  Well it's a web of trust: typically people only trust their Gemfile, not their entire Gemfile.lock. If you audit the latter you should be fine (though of course you should upgrade regardless).
- bottled_poe 9y ago
  How much do you trust the code review process on every ruby gem?
- boombip 9y ago
  Well an existing gem might not. But a gem you use has could have a developer's computer get compromised and could publish a malicious update. If you inadvertently download it while updating your gems you could get compromised. The problem here is that you don't even have to get directly attacked to be affected.
- paulie_a 9y ago
  Why go out of the way when you can just buy a popular one, this was a fairly mild version of that: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-... Granted that was just data collection, but the outcome could be incredibly worse if a combo of popular but bad code and a little bit of money.
- arkadiyt 9y ago
  There was recently a fiasco with NPM over a malicious node package whose name was an intentional typo of a popular package, and upon installation it exfiltrated all environment variables: https://twitter.com/o_cee/status/892306836199800836 https://twitter.com/o_cee/status/892306836199800836 After this got uncovered, Duo published a blog post where they scanned for and found several others malicious packages: https://duo.com/blog/hunting-malicious-npm-packages https://duo.com/blog/hunting-malicious-npm-packages The last one they talk about worms itself by adding itself to any packages authored on the computer it's installed on. These issues are not unique to npm.
- deleted 9y ago
  [deleted]
matt4077 9y ago
I don't quite understand how this is different from the status quo? I guess gems may (sometimes) be installed with a different user (or even root) than the application server? But even if: most systems today probably only run that one service, and the application server can rwx pretty much everything of interest because that's its job, right? 10 years or so ago you'd often see some company's server running apache as well as a mail server, the internal document repository and the financial systems. In that sort of setup, it's important to (try to) keep these systems isolated from each other. But today, all that root access would give you is the ability to read a few more Ubuntu man pages.
- quacker 9y ago
  I wouldn't be so optimistic. There are often credentials to other systems (like databases, etc) on such servers, plus they now have access to the private network(s) the compromised server resides on. It gives the attacker the opportunity to serve exploits to users, to forward incoming requests from users to external servers (maybe there's an auth token or something they can use), and tons of other stuff.
  - lotyrin 9y ago
    Yep. Even if you only owned a perfectly sterile (no secrets) proxy tier to a distinct service tier, you are placed in the path of requests from clients to those services and can thereby extract credentials (passwords, tokens) or PII (names, emails), which would still be unacceptable.
- pmontra 9y ago
  Developer machines could be as interesting as servers, maybe more. If they can install a keylogger using a malicious or hijacked gem, then bingo! The file overwrite and the ANSI sequence vulnerabilities are extra attack vectors. The main one has anyways been the code itself and its vetting process. This for Ruby gems and for any other open and closed source piece of code we run on our machines, starting from the processor(s) microcode.
- jrochkind1 9y ago
CJefferson 9y ago
While this is bad, most gems are executable code, which will get executed (seeing as you installed the gem). So while this is bad, I don't think it's that bad -- a malicious gem could always mess you up. Still update!
- irishsultan 9y ago
  The only difference is that you are perhaps more likely to install a gem system wide (which would require root rights normally) than run code from a locally installed gem with root rights.
Xylakant 9y ago
I don't really get the fuss about this one. It's annoying and a vector, true, but keep in mind that even with this fixed, a malicious gem can overwrite arbitrary files. A gem can bring with it a C-extension. This extension is compiled with a makefile created by the gem-provided extconf.rb. AFAIK, the code in the extconf.rb is executed at gem install time, so arbitrary code can be executed at gem install time. AFAICS this is the relevant line: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/ext_conf_builder.rb#L43 https://github.com/rubygems/rubygems/blob/master/lib/rubygem... Edit: Or, if you want to get a little more creative, have your gem include a plugin to rubygems itself, similar to what https://github.com/rvm/executable-hooks https://github.com/rvm/executable-hooks does.
- fny 9y ago
  I agree. Or how about one step away from just the installation? Once you load a gem it can do whatever the hell it wants to your system. This vulnerability feels very security-theater-ish. At the end of the day, someone needs to audit the gem or have deep trust in the supplying party (i.e. Rails) to protect against arbitrary file manipulation.
  - Xylakant 9y ago
    Installation and running are not necessarily done with the same account. Often, apps run with lower privileges than they're installed with, so the damage may be somewhat mitigated. I'd really treat that as a separate, albeit related problem.

devmunchies 9y ago

would you have to go out of your way to find a malicious gem though? Its not like any of the popular gems would try to overwrite files, right?

fish_fan 9y ago
Well it's a web of trust: typically people only trust their Gemfile, not their entire Gemfile.lock. If you audit the latter you should be fine (though of course you should upgrade regardless).
bottled_poe 9y ago
How much do you trust the code review process on every ruby gem?
boombip 9y ago
Well an existing gem might not. But a gem you use has could have a developer's computer get compromised and could publish a malicious update. If you inadvertently download it while updating your gems you could get compromised. The problem here is that you don't even have to get directly attacked to be affected.
paulie_a 9y ago
Why go out of the way when you can just buy a popular one, this was a fairly mild version of that: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-... Granted that was just data collection, but the outcome could be incredibly worse if a combo of popular but bad code and a little bit of money.
arkadiyt 9y ago
There was recently a fiasco with NPM over a malicious node package whose name was an intentional typo of a popular package, and upon installation it exfiltrated all environment variables: https://twitter.com/o_cee/status/892306836199800836 https://twitter.com/o_cee/status/892306836199800836 After this got uncovered, Duo published a blog post where they scanned for and found several others malicious packages: https://duo.com/blog/hunting-malicious-npm-packages https://duo.com/blog/hunting-malicious-npm-packages The last one they talk about worms itself by adding itself to any packages authored on the computer it's installed on. These issues are not unique to npm.
deleted 9y ago
[deleted]

matt4077 9y ago

I don't quite understand how this is different from the status quo? I guess gems may (sometimes) be installed with a different user (or even root) than the application server? But even if: most systems today probably only run that one service, and the application server can rwx pretty much everything of interest because that's its job, right? 10 years or so ago you'd often see some company's server running apache as well as a mail server, the internal document repository and the financial systems. In that sort of setup, it's important to (try to) keep these systems isolated from each other. But today, all that root access would give you is the ability to read a few more Ubuntu man pages.

quacker 9y ago
I wouldn't be so optimistic. There are often credentials to other systems (like databases, etc) on such servers, plus they now have access to the private network(s) the compromised server resides on. It gives the attacker the opportunity to serve exploits to users, to forward incoming requests from users to external servers (maybe there's an auth token or something they can use), and tons of other stuff.
- lotyrin 9y ago
  Yep. Even if you only owned a perfectly sterile (no secrets) proxy tier to a distinct service tier, you are placed in the path of requests from clients to those services and can thereby extract credentials (passwords, tokens) or PII (names, emails), which would still be unacceptable.
pmontra 9y ago
Developer machines could be as interesting as servers, maybe more. If they can install a keylogger using a malicious or hijacked gem, then bingo! The file overwrite and the ANSI sequence vulnerabilities are extra attack vectors. The main one has anyways been the code itself and its vetting process. This for Ruby gems and for any other open and closed source piece of code we run on our machines, starting from the processor(s) microcode.
jrochkind1 9y ago

CJefferson 9y ago

While this is bad, most gems are executable code, which will get executed (seeing as you installed the gem). So while this is bad, I don't think it's that bad -- a malicious gem could always mess you up. Still update!

irishsultan 9y ago
The only difference is that you are perhaps more likely to install a gem system wide (which would require root rights normally) than run code from a locally installed gem with root rights.

Xylakant 9y ago

I don't really get the fuss about this one. It's annoying and a vector, true, but keep in mind that even with this fixed, a malicious gem can overwrite arbitrary files. A gem can bring with it a C-extension. This extension is compiled with a makefile created by the gem-provided extconf.rb. AFAIK, the code in the extconf.rb is executed at gem install time, so arbitrary code can be executed at gem install time. AFAICS this is the relevant line: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/ext_conf_builder.rb#L43 https://github.com/rubygems/rubygems/blob/master/lib/rubygem... Edit: Or, if you want to get a little more creative, have your gem include a plugin to rubygems itself, similar to what https://github.com/rvm/executable-hooks https://github.com/rvm/executable-hooks does.

fny 9y ago
I agree. Or how about one step away from just the installation? Once you load a gem it can do whatever the hell it wants to your system. This vulnerability feels very security-theater-ish. At the end of the day, someone needs to audit the gem or have deep trust in the supplying party (i.e. Rails) to protect against arbitrary file manipulation.
- Xylakant 9y ago
  Installation and running are not necessarily done with the same account. Often, apps run with lower privileges than they're installed with, so the damage may be somewhat mitigated. I'd really treat that as a separate, albeit related problem.