> 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.
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.
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.
https://lwn.net/Articles/57135/
Hard to get a collision though I'm guessing.
like non-printing characters in comments?
Or, you know, random odd generated crud https://github.com/torvalds/linux/tree/master/firmware/radeo...
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.
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?
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.
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
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/]
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).
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.
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.
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...