3 ms·

For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about s

by akavlie 15y ago

For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.

rosser 15y ago
Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.
- seanp2k2 15y ago
  And we all saw what happened: Github got in gear real quick and rolled out a fix FAST. Point, dood.
- sounds 15y ago
  Let's be fair to homakov: He used the exploit publicly and loudly (full disclosure to almost all affected parties) by doing a relatively harmless change to _rails_ _master_ on github. If his actions should be called an attack, then it was highly targeted - at the people who could fix it - to get their attention.
  - arohner 15y ago
    His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
    - jbri 15y ago
      And got it fixed. Security vulnerabilities aren't the sort of things that go away just because you don't know they're there.
      - tptacek 15y ago
        From experience: had he simply told Github about it, they would have fixed it quickly, and there would have been no window of public exposure. That's the point being made here.
        sounds 15y ago
        Fair enough, that's basically what was said in the bug he filed with Ruby on Rails. I won't try to impute motives but I think he did it this way because he felt like he was being treated poorly.
        arohner 15y ago
        There are two different issues here. 1) A bad security vulnerability at GitHub. 2) Poor design in Rails that makes it easy to produce security vulnerabilities. Igor found 2, and got ignored by the Rails team. His frustration led him to publicly demonstrating 1, which caused a whole lot of people a whole lot of trouble. The people that are irritated at him are irritated at him because of 1, not 2.
        deleted 15y ago
        [deleted]
    - mhurron 15y ago
      What kind of serious company puts important or 'secure' code on github?
- ig1 15y ago
  No, he was making noise about a class of exploits and then exploited a particular instance of that exploit, which is completely different. It's like the difference between the class of buffer overflow exploits and the buffer overflow exploit in a particular piece of software. There's a significant difference between the two.
- technoweenie 15y ago
  Another clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously. We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and we are always gracious (and even contract work from them in some cases) In his case, we saw activity that he didn't report to us, and suspended his account while we did a deeper investigation. The Rails community and we still think that his proposed solution is not a good idea, but it did provoke exploration in some other ideas. https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228 http://techno-weenie.net/2012/3/19/ending-the-mass-assignment-party/ http://techno-weenie.net/2012/3/19/ending-the-mass-assignmen... http://weblog.rubyonrails.org/2012/3/21/strong-parameters/ http://weblog.rubyonrails.org/2012/3/21/strong-parameters/
  - ricardobeat 15y ago
    I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.
    - nbpoole 15y ago
      There's a difference between complaining about a class of vulnerability and exploiting a particular instance of a vulnerability that you seem to be failing to grasp. If you find a major hole in a part of Git, you are by no means obligated to tell GitHub. You are, however, legally obligated not to compromise their site using that hole. Or, a better example: you can talk about XSS mitigation strategies all you want. You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.
      - ricardobeat 15y ago
        technoweenie pointed out that he wasn't being ignored by GitHub, I was saying that's irrelevant. GH is just one of thousands of Rails apps that were/are vulnerable. > You can't go around looking for XSS vulnerabilities on random websites and then exploiting them. exploit: to use a situation so that you get benefit from it, even if it is wrong or unfair to do this; to utilize, especially for profit; etc
homakov 15y ago
I'd not say so. All new - well forgotten old.

by akavlie 15y ago

For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.

rosser 15y ago

Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.

seanp2k2 15y ago
And we all saw what happened: Github got in gear real quick and rolled out a fix FAST. Point, dood.
sounds 15y ago
Let's be fair to homakov: He used the exploit publicly and loudly (full disclosure to almost all affected parties) by doing a relatively harmless change to _rails_ _master_ on github. If his actions should be called an attack, then it was highly targeted - at the people who could fix it - to get their attention.
- arohner 15y ago
  His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
  - jbri 15y ago
    And got it fixed. Security vulnerabilities aren't the sort of things that go away just because you don't know they're there.
    - tptacek 15y ago
      From experience: had he simply told Github about it, they would have fixed it quickly, and there would have been no window of public exposure. That's the point being made here.
      - sounds 15y ago
        Fair enough, that's basically what was said in the bug he filed with Ruby on Rails. I won't try to impute motives but I think he did it this way because he felt like he was being treated poorly.
        arohner 15y ago
        There are two different issues here. 1) A bad security vulnerability at GitHub. 2) Poor design in Rails that makes it easy to produce security vulnerabilities. Igor found 2, and got ignored by the Rails team. His frustration led him to publicly demonstrating 1, which caused a whole lot of people a whole lot of trouble. The people that are irritated at him are irritated at him because of 1, not 2.
      - deleted 15y ago
        [deleted]
  - mhurron 15y ago
    What kind of serious company puts important or 'secure' code on github?
ig1 15y ago
No, he was making noise about a class of exploits and then exploited a particular instance of that exploit, which is completely different. It's like the difference between the class of buffer overflow exploits and the buffer overflow exploit in a particular piece of software. There's a significant difference between the two.
technoweenie 15y ago
Another clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously. We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and we are always gracious (and even contract work from them in some cases) In his case, we saw activity that he didn't report to us, and suspended his account while we did a deeper investigation. The Rails community and we still think that his proposed solution is not a good idea, but it did provoke exploration in some other ideas. https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228 http://techno-weenie.net/2012/3/19/ending-the-mass-assignment-party/ http://techno-weenie.net/2012/3/19/ending-the-mass-assignmen... http://weblog.rubyonrails.org/2012/3/21/strong-parameters/ http://weblog.rubyonrails.org/2012/3/21/strong-parameters/
- ricardobeat 15y ago
  I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.
  - nbpoole 15y ago
    There's a difference between complaining about a class of vulnerability and exploiting a particular instance of a vulnerability that you seem to be failing to grasp. If you find a major hole in a part of Git, you are by no means obligated to tell GitHub. You are, however, legally obligated not to compromise their site using that hole. Or, a better example: you can talk about XSS mitigation strategies all you want. You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.
    - ricardobeat 15y ago
      technoweenie pointed out that he wasn't being ignored by GitHub, I was saying that's irrelevant. GH is just one of thousands of Rails apps that were/are vulnerable. > You can't go around looking for XSS vulnerabilities on random websites and then exploiting them. exploit: to use a situation so that you get benefit from it, even if it is wrong or unfair to do this; to utilize, especially for profit; etc

homakov 15y ago

I'd not say so. All new - well forgotten old.