4 ms·

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, righ

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

azernik 10y ago
If they edit the commit history and you're using a secure hash algorithm, then the hash of the current commit will change and no longer match the signed tag your trusted maintainer sent you.
- deleted 10y ago
  [deleted]
leoh 10y ago
Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.
- yeukhon 10y ago
  Well, open source software like Linux kernel has many obvious bugs for years go without notice. But his point is still extremely fair. There may be code no one really actively updating, but to even able to add random odd crud in the source code is really really really really hard. The effort is not worth it for any reasonable attackers. One would rather exploit an existing zero day or just infect network and wait to activate the infection. If someone modifies the local source code you just git cloned (or from a tarball), well you have something to worry about - your network.
  - astrodust 10y ago
    The kernel, and OpenSSH to name another project, is full of random crud nobody noticed. Everyone does their best to review patches and ensure things are sane when going in, but there's a lot of change in projects at scale, and sometimes the standards one patch wrangler has are different from another. Mistakes happen. If at-patch time is your only code review, you've got problems. If your code base is too huge to look over frequently you've got problems.
    - ageofwant 10y ago
      And context is important as well. Worrying about sha-exploits in an environment like this is like wondering whether you watered the plants while the house burns down. The security-theater troupe wails like there's no tomorrow when their buttons get pushed. As Linus, said, given the context and the risk, its of almost no consequence.
      - astrodust 10y ago
        I'm in agreement with Linus, but it also highlights problems with code-bases this complex. We depend on code being readable to spot malicious activity. Generating a SHA1 collision to jam in a very subtle bug is highly improbable, and might even be unfeasible if the diff is small enough. There's certainly a concern if your code is more opaque, as is the case in this bug. If you're taking in raw asm.js code, for example, from various sources...
- stinos 10y ago
  If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice Unless I'm misunderstanding how this would work in practice (I assume commits being added under my name or existing commits being modified?), I'm abolutely not buying that though. Way too general, no? I would likely notice something like that, but I know enough colleagues who are just as likely to not notice. Mostly because they don't fully grasp git so they're just like 'hmm, thing says I'm behind, ha I know the fix is pull, yes I'm a git wizard' and just pull then continue working without even checking what got changed.
  - ProblemFactory 10y ago
    Sure, most people don't review all the code that they pull. But if you are in a position to insert "garbage data" into a commit in preparation for an attack, it will be much easier to insert malicious but safe-looking code in the first place. Omit an array bounds check, disable SSL certificate validation, or anything else that looks like a mistake but will allow you to compromise the running code later.
- btbuilder 10y ago
  How about very subtle in with the noise. Like this attempt to backdoor Linux in 2003: https://lwn.net/Articles/57135/ https://lwn.net/Articles/57135/ Hard to get a collision though I'm guessing.
- posterboy 10y ago
  >If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice. Just as they noticed the intrusion on kernel.org servers after how long? edit: > If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Sure, that's always true, in the worst case. Perfect security doesn't exist. But does it need to be an attacker? Couldn't it just happen that an important bugfix isn't recorded because the hash collides?
  - Dylan16807 10y ago
    > Just as they noticed the intrusion on kernel.org servers after how long? It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. > Couldn't it just happen that an important bugfix isn't recorded because the hash collides? The hashes will never collide if there's no attacker. And that bugfix would have to have a blob of crud in the 'good' version, which would stick out like a sore thumb.
    - posterboy 10y ago
      > It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. Do you assume that a proper preimage-attack would be needed? Instead, the good looking object could be committed, I guess after reading https://news.ycombinator.com/item?id=13721237 https://news.ycombinator.com/item?id=13721237 edit: > And that bugfix would have to have a blob of crud in the 'good' version Looking at google's POC, the colliding pdfs don't at all stick out (edit: but they are horribly contrived and you talked about code not blobs) [https://shattered.io/ https://shattered.io/] edit: thanks for your answer, it motivated me to learn a bit more. I'm still not sure if "never" is a rounding error, hyperbole (which would be ill advised talking to laymen), or actual fact (that source files due to the reduced entropy in byte patterns could in fact never ever collide, which I doubt).
      - Dylan16807 10y ago
        > the good looking object could be committed In source code there will be an obvious block of "hash was attacked here" crud in each file. The 'good looking' object will function non-maliciously, but it will be obvious that something is up. > I'm still not sure if "never" is a rounding error, hyperbole (which would be ill advised talking to laymen), or actual fact (that source files due to the reduced entropy in byte patterns could in fact never ever collide, which I doubt) "never" is to be read as "over a billion times more unlikely than all life on the planet suddenly being wiped out". It's not going to happen accidentally.
- posterboy 10y ago
  > random odd generated crud in the middle of your source code, you will absolutely notice like non-printing characters in comments? Or, you know, random odd generated crud https://github.com/torvalds/linux/tree/master/firmware/radeon https://github.com/torvalds/linux/tree/master/firmware/radeo...
  - ProblemFactory 10y ago
    If you were planning on getting a compromised binary blob into a git repository, you would not bother with the whole SHA-1 collision and switching things out later. You would just build a hidden backdoor into the first binary blob, like a deliberately omitted array bounds check if specific parameters are used. Reviewers and tests won't find that in complied binary code either, it's much easier to hide than large amounts of garbage data, and you even get to keep plausible deniability of it being a honest mistake if discovered.
    - posterboy 10y ago
      also to divert my criticism, that directory is not for new commits

azernik 10y ago

If they edit the commit history and you're using a secure hash algorithm, then the hash of the current commit will change and no longer match the signed tag your trusted maintainer sent you.

deleted 10y ago
[deleted]

leoh 10y ago

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

yeukhon 10y ago
Well, open source software like Linux kernel has many obvious bugs for years go without notice. But his point is still extremely fair. There may be code no one really actively updating, but to even able to add random odd crud in the source code is really really really really hard. The effort is not worth it for any reasonable attackers. One would rather exploit an existing zero day or just infect network and wait to activate the infection. If someone modifies the local source code you just git cloned (or from a tarball), well you have something to worry about - your network.
- astrodust 10y ago
  The kernel, and OpenSSH to name another project, is full of random crud nobody noticed. Everyone does their best to review patches and ensure things are sane when going in, but there's a lot of change in projects at scale, and sometimes the standards one patch wrangler has are different from another. Mistakes happen. If at-patch time is your only code review, you've got problems. If your code base is too huge to look over frequently you've got problems.
  - ageofwant 10y ago
    And context is important as well. Worrying about sha-exploits in an environment like this is like wondering whether you watered the plants while the house burns down. The security-theater troupe wails like there's no tomorrow when their buttons get pushed. As Linus, said, given the context and the risk, its of almost no consequence.
    - astrodust 10y ago
      I'm in agreement with Linus, but it also highlights problems with code-bases this complex. We depend on code being readable to spot malicious activity. Generating a SHA1 collision to jam in a very subtle bug is highly improbable, and might even be unfeasible if the diff is small enough. There's certainly a concern if your code is more opaque, as is the case in this bug. If you're taking in raw asm.js code, for example, from various sources...
stinos 10y ago
If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice Unless I'm misunderstanding how this would work in practice (I assume commits being added under my name or existing commits being modified?), I'm abolutely not buying that though. Way too general, no? I would likely notice something like that, but I know enough colleagues who are just as likely to not notice. Mostly because they don't fully grasp git so they're just like 'hmm, thing says I'm behind, ha I know the fix is pull, yes I'm a git wizard' and just pull then continue working without even checking what got changed.
- ProblemFactory 10y ago
  Sure, most people don't review all the code that they pull. But if you are in a position to insert "garbage data" into a commit in preparation for an attack, it will be much easier to insert malicious but safe-looking code in the first place. Omit an array bounds check, disable SSL certificate validation, or anything else that looks like a mistake but will allow you to compromise the running code later.
btbuilder 10y ago
How about very subtle in with the noise. Like this attempt to backdoor Linux in 2003: https://lwn.net/Articles/57135/ https://lwn.net/Articles/57135/ Hard to get a collision though I'm guessing.
posterboy 10y ago
>If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice. Just as they noticed the intrusion on kernel.org servers after how long? edit: > If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Sure, that's always true, in the worst case. Perfect security doesn't exist. But does it need to be an attacker? Couldn't it just happen that an important bugfix isn't recorded because the hash collides?
- Dylan16807 10y ago
  > Just as they noticed the intrusion on kernel.org servers after how long? It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. > Couldn't it just happen that an important bugfix isn't recorded because the hash collides? The hashes will never collide if there's no attacker. And that bugfix would have to have a blob of crud in the 'good' version, which would stick out like a sore thumb.
  - posterboy 10y ago
    > It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people. Do you assume that a proper preimage-attack would be needed? Instead, the good looking object could be committed, I guess after reading https://news.ycombinator.com/item?id=13721237 https://news.ycombinator.com/item?id=13721237 edit: > And that bugfix would have to have a blob of crud in the 'good' version Looking at google's POC, the colliding pdfs don't at all stick out (edit: but they are horribly contrived and you talked about code not blobs) [https://shattered.io/ https://shattered.io/] edit: thanks for your answer, it motivated me to learn a bit more. I'm still not sure if "never" is a rounding error, hyperbole (which would be ill advised talking to laymen), or actual fact (that source files due to the reduced entropy in byte patterns could in fact never ever collide, which I doubt).
    - Dylan16807 10y ago
      > the good looking object could be committed In source code there will be an obvious block of "hash was attacked here" crud in each file. The 'good looking' object will function non-maliciously, but it will be obvious that something is up. > I'm still not sure if "never" is a rounding error, hyperbole (which would be ill advised talking to laymen), or actual fact (that source files due to the reduced entropy in byte patterns could in fact never ever collide, which I doubt) "never" is to be read as "over a billion times more unlikely than all life on the planet suddenly being wiped out". It's not going to happen accidentally.
posterboy 10y ago
> random odd generated crud in the middle of your source code, you will absolutely notice like non-printing characters in comments? Or, you know, random odd generated crud https://github.com/torvalds/linux/tree/master/firmware/radeon https://github.com/torvalds/linux/tree/master/firmware/radeo...
- ProblemFactory 10y ago
  If you were planning on getting a compromised binary blob into a git repository, you would not bother with the whole SHA-1 collision and switching things out later. You would just build a hidden backdoor into the first binary blob, like a deliberately omitted array bounds check if specific parameters are used. Reviewers and tests won't find that in complied binary code either, it's much easier to hide than large amounts of garbage data, and you even get to keep plausible deniability of it being a honest mistake if discovered.
  - posterboy 10y ago
    also to divert my criticism, that directory is not for new commits