If I'm understanding it right, you got it right the second time. It's not enough for a trusted user to modify their own copy, all they've done is attack themselves. You'd have to compromise the...
If I'm understanding it right, you got it right the second time. It's not enough for a trusted user to modify their own copy, all they've done is attack themselves. You'd have to compromise the central repository where everyone pulls from and poison the well.
They address a real world example where this could have happened: Essentially, the attacker could have poisoned the server's copy of floppy.c, and since HEAD's hash would still match, no one would...
They address a real world example where this could have happened:
The compromise of kernel.org in 2011 created a fair amount of concern about the security of the kernel source repository. If an attacker were able to put a backdoor into the kernel code, the result could be the eventual compromise of vast numbers of deployed systems.
Essentially, the attacker could have poisoned the server's copy of floppy.c, and since HEAD's hash would still match, no one would suspect anything. Then, any clones from kernel.org would result in the poisoned file being returned, which would slowly start to poison many people's kernel repositories. Depending on where in the code base the backdoor was inserted, it could be a long time before people find the vulnerability and trace its source.
If this were to happen on the scale of GitHub, there would be madness (though, Linux is infrastructure-critical too). They could selectively poison individual projects, or even individual developer's repositories, without any major red flags.
Let me preface this by stating that I can use git as a user, but I do not know its inner workings. I can see another attack vector. First perform a man in the middle attack between the target and...
Let me preface this by stating that I can use git as a user, but I do not know its inner workings.
I can see another attack vector. First perform a man in the middle attack between the target and the central git server. (I know this is not trivial, but heartbleed and other vulnerabilities exist.) When the target clones the repo to compile a new kernel for their machines, you send the collision floppy.c instead of the good one. Git won't complain, and the chance that the target individual/company will read every line of source to find the garbled and Rick rolled file is close to zero (this also means that you don't need to make the hash collision file look like normal code too). Then, when the fresh new kernel is deployed to the companies servers, we have wonderful Rick hash collisioned code built in.
That would be what the Offtopic label is for. Malice is strictly reserved for comments that Deimos might potentially need to intervene on... think of it like the "report" function on reddit but...
Folks, feel free to label this as malice, I know it has nothing to do with SHA-1 or Git.
That would be what the Offtopic label is for. Malice is strictly reserved for comments that Deimos might potentially need to intervene on... think of it like the "report" function on reddit but one that goes directly to the admins instead of the community moderators.
p.s. I realize you may have just been joking, but just in case any new users see your comment I wanted to make it clear what Malice was actually for. ;)
Yes, and @deing has actually even done a bunch of work implementing it already. See: https://gitlab.com/tildes/tildes/issues/317 https://gitlab.com/tildes/tildes/-/merge_requests/73
"progress" Just add a file to your repo that has a sha-256 (or whatever hash) of the files in your git repo. A git extension could solve this problem trivially and it would still be backwards...
"progress" Just add a file to your repo that has a sha-256 (or whatever hash) of the files in your git repo. A git extension could solve this problem trivially and it would still be backwards compatible. The idea that we need a breaking change to suit a small group of users is silly.
If I'm understanding it right, you got it right the second time. It's not enough for a trusted user to modify their own copy, all they've done is attack themselves. You'd have to compromise the central repository where everyone pulls from and poison the well.
They address a real world example where this could have happened:
Essentially, the attacker could have poisoned the server's copy of
floppy.c, and since HEAD's hash would still match, no one would suspect anything. Then, any clones from kernel.org would result in the poisoned file being returned, which would slowly start to poison many people's kernel repositories. Depending on where in the code base the backdoor was inserted, it could be a long time before people find the vulnerability and trace its source.If this were to happen on the scale of GitHub, there would be madness (though, Linux is infrastructure-critical too). They could selectively poison individual projects, or even individual developer's repositories, without any major red flags.
Let me preface this by stating that I can use git as a user, but I do not know its inner workings.
I can see another attack vector. First perform a man in the middle attack between the target and the central git server. (I know this is not trivial, but heartbleed and other vulnerabilities exist.) When the target clones the repo to compile a new kernel for their machines, you send the collision floppy.c instead of the good one. Git won't complain, and the chance that the target individual/company will read every line of source to find the garbled and Rick rolled file is close to zero (this also means that you don't need to make the hash collision file look like normal code too). Then, when the fresh new kernel is deployed to the companies servers, we have wonderful Rick hash collisioned code built in.
That an Inglourious Basterds reference?
That would be what the Offtopic label is for. Malice is strictly reserved for comments that Deimos might potentially need to intervene on... think of it like the "report" function on reddit but one that goes directly to the admins instead of the community moderators.
p.s. I realize you may have just been joking, but just in case any new users see your comment I wanted to make it clear what Malice was actually for. ;)
Yes, and @deing has actually even done a bunch of work implementing it already. See:
https://gitlab.com/tildes/tildes/issues/317
https://gitlab.com/tildes/tildes/-/merge_requests/73
"progress" Just add a file to your repo that has a sha-256 (or whatever hash) of the files in your git repo. A git extension could solve this problem trivially and it would still be backwards compatible. The idea that we need a breaking change to suit a small group of users is silly.