Hacker News Reader

Comment by revelation | Hacker News Reader

So, did they have time for a git blame yet? It's one thing to say you have found a backdoor, another is to clear up how it got there in the first place.

View on HN

If you are capable of inserting this kind of backdoor, how easy is it to compromise a version control system? (or the login details of one of the programmers?).

Is it possible to prevent history of the code being modified? Do DVCS use blockchains?

If a git commit is modified, every commit hash after it will change and will break every clone.

That's a system that would still be entirely vulnerable to collision attacks, though, right?

I'd imagine it would be nearly impossible to generate a collision that a.) does what you want, b.) is small enough to be unobtrusive, and c.) can be discovered in finite time with the computing power reasonably available to NSA/GCHQ/insert SIGINT organization of choice.

I asked because git uses SHA1, which might be a bit low on (c) at this point.

True. Generating collisions is doable, but a.) and b.) are still huge constraints that make it orders of magnitude more difficult.

True, it could've been easier to use fake credentials from the start

git blame will only really help if the backdoor was inserted into the original code (and even then stolen credentials are possible) AFAIK. It's fairly easy to imagine a scenario where this is not the case:

* Compromised build script - probably under source control as well? * Compromised compiler - If the attackers had this level of access, they probably had enough access to erase logs showing who/when the compiler was replaced * Binary patch the compiler output - Not impossible (though I suspect unlikely?) that the original source and build system are clean, but the binary is tampered with after the fact.

So ... my plan is to put the tuple (hash(source), hash(bin)) into the blockchain as a part of each build ... could this work?

Reply on news.ycombinator.com