Hacker News new | ask | show | jobs
by The_Colonel 811 days ago
> If you try to, then others will notice that the hashes mismatch and that their HEAD diffs uncleanly.

So it relies on a human noticing and acting upon it. People not noticing backdoors being merged into the project is kinda the source of this problem.
1 comments
fl7305 811 days ago
You can automate checks for if a large part of the previous git history suddenly changed.

You can't automate checks for malicious code.

link
The_Colonel 811 days ago
That relies on some heuristics which can be worked around, unless you disallow rewriting history.

But the bigger issue is that this is some theoretical system which is not present in most git repositories.

link
fl7305 811 days ago
The heuristic would be "sound the alarm if the main branch is rewritten". And maybe also "if a release tag that we have used for our distro is moved".

Wouldn't that catch most problems, and not generate too many false alarms?

link
The_Colonel 810 days ago
You can rename/switch branches. You can change what branch is considered main/master. You can find valid reasons why you'd want to do stuff which raises the alarms so that other people become deaf to them, and only then execute the rewriting attack. Relying on people noticing (even with alarms) is just super fragile.
link
fl7305 810 days ago
> You can rename/switch branches. You can change what branch is considered main/master.

Sure, in the project repo the branches are just simple text files that contain the hashes of the commits they point to.

So they are trivial to change in the project repo. But it is also trivial for the distro project to keep copies of the branch/tag info and check against those. I guess what you mainly care about are the previous release tags. They should never change after a release.

> Relying on people noticing (even with alarms) is just super fragile.

I'd say there's plenty of motivation now for the major distros to put infrastructure in place to automate this (keeping track of previous releases) and to actually keep looking at the alarms.

> You can find valid reasons why you'd want to do stuff which raises the alarms so that other people become deaf to them

I'm sure the attackers would try things like that.

But let's say you have an open source application/library that is part of Debian.

How common has it been in the past that the app/lib project had a bunch of tagged releases, and then wanted to rewrite the history so that the tagged releases now point to different commits? I assume it has been very uncommon, but maybe I'm wrong?

And even if that is the case, new infrastructure tools can keep local copies of the source code for previous releases, and check against that.

Repo checking is not trivial, perfect, or sufficient. But I'd say it's a necessary component in guarding against attacks.

The big challenge is still that there is so much code added/changed for each new release of apps/libs that it is very difficult to check against attacks. The obfuscated C contest has proven again and again how hard it is.

link