5 ms·

This story, and the recent RubyGems debacle should be teaching all of us one thing -- assume you can and will be hacked. Do you understand the implications (wh

This story, and the recent RubyGems debacle should be teaching all of us one thing -- assume you can and will be hacked. Do you understand the implications (what data you are going to lose? what credibility?) Do you have a plan to deal with it? Ruby Gems was lucky in that their hack was noisy. The chinese government, as illustrated above, won't play so nice. This is why monitoring and incident response matter. Remember the subtle backdoor that almost slipped into the Linux kernel in 2003[1]? That could be Ruby Gems right now. Hopefully, they are taking the proper steps to investigate exactly what the hackers did. [1] http://kerneltrap.org/node/1584 http://kerneltrap.org/node/1584

pifflesnort 14y ago
China appears to be engaging in highly sophisticated attacks of the like that major companies need to be aware. The RubyGems fiasco is the result of remarkably incompetent decisions by everyone in the chain of control. The lessons are completely different. In the first, it's that you have to expect that you will be compromised if a determined and capable attacker targets you. In the second, it's that you will be compromised if you use software written by people and maintained by a community that seemingly lacks any remote resemblance of engineering competence.
- jenandre 14y ago
  I don't think the RubyGems people were incompetent. The software serves its core purpose quite well (as a library delivery mechanism) and is quite reliable. But clearly they weren't thinking about security in decision, and what would happen if the repos were compromised. Let's be honest here - no software is 100% secure. As developers and consumers, the idea that we all review all of the tools in our toolchain for security soundness is absurd. It's like saying that everyone using C made poor decisions because of security flaws in popular libraries (even security ones, like openssl) and therefore all of the C community has no engineering competence. The fact is, China already has their eyes on GitHub and it's not beyond the planning capability to place backdoors in popular software to suit their future ends. No matter who the attacker may be, you have to be prepared for the situation where your computers and data are compromised, period.
  - pifflesnort 14y ago
    > I don't think the RubyGems people were incompetent. They sat on a publicly disclosed vulnerability in the YAML parser for a week. The YAML parser itself was ridiculously designed to (essentially) eval() YAML. Those were the two active decisions of incompetence. On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. There is no telling what people could have injected into that repository at any point in its history.
    - ceejayoz 14y ago
      > On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. https://github.com/rubygems/rubygems/blob/master/History.txt https://github.com/rubygems/rubygems/blob/master/History.txt 0.8.11 / 2005-07-13: Added Paul Duncan's gem signing patch. They've had a mechanism for code signing for 8 years. Yes, they could require signing of all gems on the site, but the ability has been there for a long time.
      - pifflesnort 14y ago
        This doesn't do any good if it's not required/used, which it's not. As a counter-example, the maven central repository requires signatures, and caching Maven repositories validate those signatures.
        ceejayoz 14y ago
        I'm simply contesting the "no means of code verification whatsoever" statement.
        pifflesnort 14y ago
        My point is simply that without signatures, there is no means of verification. Having the code isn't enough.

pifflesnort 14y ago

China appears to be engaging in highly sophisticated attacks of the like that major companies need to be aware. The RubyGems fiasco is the result of remarkably incompetent decisions by everyone in the chain of control. The lessons are completely different. In the first, it's that you have to expect that you will be compromised if a determined and capable attacker targets you. In the second, it's that you will be compromised if you use software written by people and maintained by a community that seemingly lacks any remote resemblance of engineering competence.

jenandre 14y ago
I don't think the RubyGems people were incompetent. The software serves its core purpose quite well (as a library delivery mechanism) and is quite reliable. But clearly they weren't thinking about security in decision, and what would happen if the repos were compromised. Let's be honest here - no software is 100% secure. As developers and consumers, the idea that we all review all of the tools in our toolchain for security soundness is absurd. It's like saying that everyone using C made poor decisions because of security flaws in popular libraries (even security ones, like openssl) and therefore all of the C community has no engineering competence. The fact is, China already has their eyes on GitHub and it's not beyond the planning capability to place backdoors in popular software to suit their future ends. No matter who the attacker may be, you have to be prepared for the situation where your computers and data are compromised, period.
- pifflesnort 14y ago
  > I don't think the RubyGems people were incompetent. They sat on a publicly disclosed vulnerability in the YAML parser for a week. The YAML parser itself was ridiculously designed to (essentially) eval() YAML. Those were the two active decisions of incompetence. On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. There is no telling what people could have injected into that repository at any point in its history.
  - ceejayoz 14y ago
    > On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. https://github.com/rubygems/rubygems/blob/master/History.txt https://github.com/rubygems/rubygems/blob/master/History.txt 0.8.11 / 2005-07-13: Added Paul Duncan's gem signing patch. They've had a mechanism for code signing for 8 years. Yes, they could require signing of all gems on the site, but the ability has been there for a long time.
    - pifflesnort 14y ago
      This doesn't do any good if it's not required/used, which it's not. As a counter-example, the maven central repository requires signatures, and caching Maven repositories validate those signatures.
      - ceejayoz 14y ago
        I'm simply contesting the "no means of code verification whatsoever" statement.
        pifflesnort 14y ago
        My point is simply that without signatures, there is no means of verification. Having the code isn't enough.