On 30/03/24 23:09, Simon Josefsson wrote:
Russ Allbery <r...@debian.org> writes:
Simon Josefsson <si...@josefsson.org> writes:
Sean Whitton <spwhit...@spwhitton.name> writes:
We did some analysis on the SHA1 vulnerabilities and determined that
they did not meaningfully affect dgit & tag2upload's design.
Can you share that analysis? As far as I understand, it is possible for
a malicious actor to create a git repository with the same commit id as
HEAD, with different historic commits and tree content. I thought a
signed tag is merely a signed reference to a particular commit id. If
that commit id is a SHA1 reference, that opens up for ambiguity given
recent (well, 2019) results on SHA1. Of course, I may be wrong in any
of the chain, so would appreciate explanation of how this doesn't work.
I believe you're talking about two different things. I think Sean is
talking about preimage resistance, which assumes that the known-good
repository is trusted, and I believe Simon is talking about manufactured
collisions where the attacker controls both the good and the bad
repository.
Right. I think the latter describes the xz scenario: someone could have
pushed a maliciously crafted commit with a SHA1 collision commit id, so
there are two different git repositories with that commit id, and a
signed git tag on that commit id authenticates both trees, opening up
for uncertainty about what was intended to be used. Unless I'm missing
some detail of how git signed tag verification works that would catch
this.
Git contains a couple of countermeasures meant to greatly reduce the
practical feasibility of such manipulations.
The first is the fact that it uses a hardened SHA-1 function that
produces different hashes when it is fed one of the known collision
seeds ("disturbance vectors"). This hardened version of SHA-1 is only
resistant against known attacks, but it substantially raises the bar
from "use one of these files downloaded from the Web" to "set up your
own collision generator that will work only once for this specific
attack and once discovered will no longer work".
From https://lwn.net/Articles/716093/
Git can be configured with the USE_SHA1DC build time configuration
variable to use SHA-1 implementation from shattered.io that detects
attempted collisions
From https://shattered.io/
Is Hardened SHA-1 vulnerable? No, SHA-1 hardened with
counter-cryptanalysis (see ‘how do I detect the attack’) will detect
cryptanalytic collision attacks.
The second countermeasure is the fact that if two objects (e.g.,
commits) happen to have the same hash, then Git will use the one it has
seen first. In the common case in which the original author has pushed a
commit and the attacker subsequently pushed a malicious version of that
commit with the same hash, then all people that fetch that repository
will always see (as in, write to disk during a checkout) the original
version, not the malicious version. The malicious version will still be
in the git pack, but git will ignore it.
From https://marc.info/?l=git&m=115678778717621&w=2
Nope. If it has the same SHA1, it means that when we receive the
object from the other end, we will _not_ overwrite the object we
already have. […] if we ever see a collision, the "earlier" object
in any particular repository will always end up overriding
With these countermeasures in places, in order to successfully pull a
collusion attack, the attacker must:
1. Create an unseen collision seed.
2. Have access to the server that hosts the official repo to remove
traces of the original commit.
3. Hope that nobody pulled the repo before they tampered it.
4. Hope that nobody will notice a series of random characters being
shown during operations like git log -p.
Sure, SHA1 is broken, should be avoided and not relied upon. And many
people can easily see how to work around the countermeasures put in
place by SHA1.
But pulling a successful collision attack is not a trivial task. For
instance, the xz attacker did not have all that was required to carry it
out (for example they had no direct access to the git servers... yet).
Regards,
--
Gioele Barabucci
