7 ms·

I'm surprised that rubygems.org of all places did not see fit to patch the vulnerability that's now known for multiple weeks and which has been declared to be i

by pilif 14y ago

I'm surprised that rubygems.org of all places did not see fit to patch the vulnerability that's now known for multiple weeks and which has been declared to be incredibly dangerous and for which ready-made exploit kits exist. rubygems.org is a central distribution platform trusted by tons and tons of projects. As such, that site is the one site you probably do not ever want compromized. Imagine the damage an attacker could deal by uploading backdoored versions of various popular gems. I know - applying security patches is time-consuming and we are all afraid of breakage. But the moment rubygems.org stepped up to be a semi-official central distribution point for gems, I would have hoped they also took on the responsibility that goes along with that. If this was some new unknown 0day exploit, I would be much more understanding, but this was known to exist, known to be dangerous, known to be exploited.

steveklabnik 14y ago
This is not that vulnerability. Their Rails is just fine. This is related to the fact that gems use YAML to store their metadata.
- 1qaz2wsx3edc 14y ago
  Semi related CVEs aside (CVE-2013-0333 and CVE-2013-0156): YAML's security problems have been known for years by the community. YAML aside, don't trust user input. This is egg on rubygems's face and the ruby community. I don't think http://rubycentral.org/ http://rubycentral.org/ has full-time staff for rubygems either. Gems, specifically should be signed. They are not, this type of exploit will continue to happen, hell, remember when github screwed up ssh keys? Who knows what's in the ecosystem. TL;DR; Ruby's security ecosystem is butter. Disclaimer: I love ruby and use it daily. It was two critical problems IMO: unsigned code and GIL. Yes, GIL. I'm looking at you ruby-core.
  - charliesome 14y ago
    The GIL is not really a problem. There are far more pressing issues with MRI, and many core developers are working hard to solve these.
    - krickle 14y ago
      Like what? I thought the GIL and GC forcing COW were the largest problems bar none.
  - deleted 14y ago
    [deleted]
  - quadhome 14y ago
    How would signing gems have prevented this situation?
    - cbhl 14y ago
      It would allow you to verify the authenticity of the gems, even if the server had been compromised. (This isn't a new technique -- for example, .deb packages distributed through APT are usually signed with gpg -- IIRC, this was a measure introduced years ago in response to a Debian mirror being compromised.)
      - quadhome 14y ago
        (my knowledge is circa early 2000s) Debian has (had?) a high barrier to entry to become a developer, and every developer signs their packages. The release binaries are arranged on a secured box and the release key itself is held by a limited set of people. In short, the signatures work because of the human element and organizational structure of Debian. Rubygems accepts submissions from the general public. So, again, I don't see how it would have helped.

by pilif 14y ago

steveklabnik 14y ago

This is not that vulnerability. Their Rails is just fine. This is related to the fact that gems use YAML to store their metadata.

1qaz2wsx3edc 14y ago
Semi related CVEs aside (CVE-2013-0333 and CVE-2013-0156): YAML's security problems have been known for years by the community. YAML aside, don't trust user input. This is egg on rubygems's face and the ruby community. I don't think http://rubycentral.org/ http://rubycentral.org/ has full-time staff for rubygems either. Gems, specifically should be signed. They are not, this type of exploit will continue to happen, hell, remember when github screwed up ssh keys? Who knows what's in the ecosystem. TL;DR; Ruby's security ecosystem is butter. Disclaimer: I love ruby and use it daily. It was two critical problems IMO: unsigned code and GIL. Yes, GIL. I'm looking at you ruby-core.
- charliesome 14y ago
  The GIL is not really a problem. There are far more pressing issues with MRI, and many core developers are working hard to solve these.
  - krickle 14y ago
    Like what? I thought the GIL and GC forcing COW were the largest problems bar none.
- deleted 14y ago
  [deleted]
- quadhome 14y ago
  How would signing gems have prevented this situation?
  - cbhl 14y ago
    It would allow you to verify the authenticity of the gems, even if the server had been compromised. (This isn't a new technique -- for example, .deb packages distributed through APT are usually signed with gpg -- IIRC, this was a measure introduced years ago in response to a Debian mirror being compromised.)
    - quadhome 14y ago
      (my knowledge is circa early 2000s) Debian has (had?) a high barrier to entry to become a developer, and every developer signs their packages. The release binaries are arranged on a secured box and the release key itself is held by a limited set of people. In short, the signatures work because of the human element and organizational structure of Debian. Rubygems accepts submissions from the general public. So, again, I don't see how it would have helped.