Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Giovanni Biscuolo]

Hello,

general reminder: please remember the specific scope of this (sub)thread

--8<---------------cut here---------------start------------->8---

 Please consider that this (sub)thread is _not_ specific to xz-utils but
 to the specific attack vector (matrix?) used to inject a backdoor in a
 binary during a build phase, in a _very_ stealthy way.

 Also, since Guix _is_ downstream, I'd like this (sub)thread to
 concentrate on what *Guix* can/should do to strenghten the build process
 /independently/ of what upstreams (or other distributions) can/should
 do.

--8<---------------cut here---------------end--------------->8---
(8734s1mn5p.fsf@xelera.eu/">https://yhetil.org/guix/8734s1mn5p.fsf@xelera.eu/)

...and if needed read that message again to understand the context,
please.

Andreas Enge <andreas@enge.fr> writes:

> Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga:
>> I think it's just better to
>> obtain the exact same code that is easy to find
>
> The exact same code as what?

Of what is contained in the official tool used by upstream to track
their code, that is the one and _only_ that is /pragmatically/ open to
scrutiny by other upstream and _downstream_ contributors.

> Actually I often wonder when looking for a project and end up with a
> Github repository how I could distinguish the "original" from its
> clones in a VCS.

Actually it's a little bit of "intelligence work" but it's something
that usually downstream should really do: have a reasonable level of
trust that the origin is really the upstream one.

But here we are /brainstormig/ about the very issue that led to the
backdoor injection, and that issue is how to avoid "backdoor injections
via build subversion exploiting semi-binary seeds in release tarballs".
(see the scope above)

> With the signature by the known (this may also be a wrong assumption,
> admittedly) maintainer there is at least some form of assurance of
> origin.

We should definitely drop the idea of "trust by autority" as a
sufficient requisite for verifiability, that is one assumption for
reproducible builds.

The XZ backdoor injection absolutely demonstrates that one and just one
_co-maintainer_ was able to hide a trojan in the _signed_ release
tarball and the payload in the git archive (as very obfuscated bynary),
so it was _the origin_ that was "infected".

It's NOT important _who_ injected the backdoor (and in _was_ upstream),
but _how_.

In other words, we need a _pragmatic_ way (possibly with helping tools)
to "challenge the upstream authority" :-)

>> and everybody is reading.
>
> This is a steep claim! I agree that nobody reads generated files in
> a release tarball, but I am not sure how many other files are actually
> read.

Let's say that at least /someone/ should be _able_ to read the files,
but in the attack we are considering /no one/ is _pragmatically_ able to
read the (auto)generated semi-binary seeds in the release tarballs.

Security is a complex system, especially when considering the entire
supply chain: let's focus on this _specific_ weakness of the supply
chain. :-)


Ciao! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature