4 ms·

Point 7 is dangerously wrong. The vulnerability allowed a malicious user to commit code under the identity of a a friendly user. The attacker could not have alt

Point 7 is dangerously wrong. The vulnerability allowed a malicious user to commit code under the identity of a a friendly user. The attacker could not have altered history, but he could have pushed his exploit on top. Chances are that it might have passed as a legitimate commit by that person.

eridius 15y ago
That's assuming nobody ever looks at anyone else's commits. Inserting an exploit into someone else's software by pushing a new commit on top is extremely risky, because it's highly likely that someone will actually look at the commit and notice it's doing something wrong. Inserting malicious commits into the history of a repository is what an attacker would love to do, because nobody is going to pore over the old history of the repo, and this is exactly what git is going to prevent.
- awj 15y ago
  I don't trust the "many eyeballs" approach anywhere near that much. I doubt that a lot of people will look too closely at something dhh supposedly committed, and even if they were worried by what they saw they may put trust in the system (and the "developer") and decide that they're simply misreading it. Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
- Xylakant 15y ago
  Well, take a shotgun approach, insert vulnerabilities in multiple repos. Or obfuscate the attempt - insert a small vulnerability in one of the libraries that rails uses (let's take a mailer lib) and that only gets triggered when certain obscure preconditions are met and then push a commit on top of rails that creates the required preconditions. Instant exploit - and each commit by itself may very well look innocent. Or spread the exploit over multiple commits, each one innocent enough, each one with a different user. Be creative, you'll find a way. And even if it's caught, then the risk fingers pointing at you will be minimal.

eridius 15y ago

That's assuming nobody ever looks at anyone else's commits. Inserting an exploit into someone else's software by pushing a new commit on top is extremely risky, because it's highly likely that someone will actually look at the commit and notice it's doing something wrong. Inserting malicious commits into the history of a repository is what an attacker would love to do, because nobody is going to pore over the old history of the repo, and this is exactly what git is going to prevent.

awj 15y ago
I don't trust the "many eyeballs" approach anywhere near that much. I doubt that a lot of people will look too closely at something dhh supposedly committed, and even if they were worried by what they saw they may put trust in the system (and the "developer") and decide that they're simply misreading it. Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
Xylakant 15y ago
Well, take a shotgun approach, insert vulnerabilities in multiple repos. Or obfuscate the attempt - insert a small vulnerability in one of the libraries that rails uses (let's take a mailer lib) and that only gets triggered when certain obscure preconditions are met and then push a commit on top of rails that creates the required preconditions. Instant exploit - and each commit by itself may very well look innocent. Or spread the exploit over multiple commits, each one innocent enough, each one with a different user. Be creative, you'll find a way. And even if it's caught, then the risk fingers pointing at you will be minimal.