Since this vulnerability has been known about for years and experienced crackers have presumably checked for it before, is there any reason to be concerned about more malicious corruption of other repositories on github?
The problems with update_attributes have been known, and messing with things like timestamps probably has been done before, but Rails itself didn't violate any acls. All users still can only access their own resources via Rails.
This attack was a combination of Rails and git/ssh keys. There's a bit of a clever aspect to it, one that isn't implied merely by understanding the vulnerabilities of update_attributes. While I think it is likely someone else has thought of it before, it is a little more exotic than something your average cracker is going to try.
Really? How is this exotic? Simple inspection of the rails form will reveal attribute and model names. And as Homarov proves, you don't need to even leave the friendly interface of the inspector to POST what you want.
The only reason why a cracker hasn't tried this is because it seems too simple to work.
OK, but that doesn't really answer my question, which is why people aren't more concerned about earlier more surreptitious corruptions of the repositories of github via the same vulnerability. It's got to have been an attractive target for the likes of the Operation Aurora [1] folks.
Presumably, Github could check for this activity by finding all public key submissions in which a public key registration involved a user id that is not the same user id as the signed-in user who submitted that. I'm not sure that's a simple DB query though...
it would still be pretty difficult to insert malicious code into a git repo, you would need to add a new commit to the end without being noticed. modifying earlier commits would be possible but git would complain when someone pulled from it in order to update a repository because the hashes wouldn't match up. New clones would work fine though.
