Fw: [arch-general] Sébastien Luttringer and Tobias Powalowski

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Fw: [arch-general] Sébastien Luttringer and Tobias Powalowski

Santiago Torres
I think this didn't get here...

I saw a couple of patches passed around regarding this issue.


> Thats is exactly what I mean. If I understood right you can modify the
> git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
> is gpg signed and all valid. This seems to work for me.
> I've added sangy to this email, he is the author of this presentation
> and should know best. sangy, can you please give us some more detailed
> information if an attack could still compromise the systemd package with
> a modified git source but still gpg signed commits?
> ~Nico
Hello, sorry for the radio silence on my part. I've been moving
apartments so I was offline for a little bit while setting up the new
internet contract...

This is true, someone can simply change the "soft" ref and trick git
into using the wrong tag/branch, be it for installation, merging etc.
Although there are some approaches that can mitigate this case (e.g.,
the signed-push solution), there is still very few people using it. I
hope that changes, mainly through visibility. Thanks Nico for pointing
this out.

I don't think I need to explain how to carry the attack anymore --- I
see eschwartz already showed how easy it is to achieve. I'd like to add
that anyone with a write access to the repository could also do this.
Consider that a lot of git repositories have been hacked in the past
(GitHub, kernel.org, RubyGems, Sourceforge, and the FSF come to mind,
but there are plenty of examples in the paper) and, while breaking sha1
is still theoretical for the purpose of attacking git, sneaking
something like this takes mere seconds and would hardly raise any

The git developers are aware of is, and they were hoping package
managers integrated these fixes (as erring verification could make it
backwards uncompatible). I see that the patchset that I submitted (and
should be available from git 2.9) was already passed around. The patch
pretty much allowed --format to be used with git tag -v and git
verify-tag accordingly. Ideally, a simple check against git tag -v
--format=%(tag) should be "robust" enough. I hope that, as time passes,
this check will become part of the "natural" tag verification invocation
and this doesn't have to be hardcoded in package managers.

Please let me know if there is anything unclear on what I said :)


signature.asc (849 bytes) Download Attachment