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

[Giovanni Biscuolo]

Hello Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of
>> tampered .m4 macros (and other possibly tampered build configuration
>> script)?
>>
>> IMHO "ignoring" (deleting) pre-built build scripts in Guix
>> build-system(s) should be considered... or is /already/ so?
>
> The gnu-build-system has a bootstrap phase, but it only does something
> when a configure script does not already exist.  We sometimes force it
> to bootstrap the build system when we patch configure.ac.
>
> In previous discussions there were no big objections to always
> bootstrapping the build system files from autoconf/automake sources.

But AFAIU the boostrap is not always done, right?

If so, given that there are no big objections to always bootstrap the
build system files, what is the technical reason it's not done?

> This particular backdoor relied on a number of obfuscations:
>
> - binary test data.  Nobody ever looks at binaries.

Yes, and the presence of binary data (e.g. for testing or other included
media) is not something under downstream (Guix) control, so we have to
live with it.  No?

> - incomprehensibility of autotools output.  This one is fundamentally a
>   social problem and easily extends to other complex build systems.  In
>   the xz case, the instructions for assembling the shell snippets to
>   inject the backdoor could hide in plain sight, just because configure
>   scripts are expected to be near incomprehensible.  They contain no
>   comments, are filled to the brim with portable (lowest common
>   denominator) shell magic, and contain bizarrely named variables.

Yes I understand this well, for this reason I call configure scripts
near-binary-artifacts, kinda *.o files

From a reproducibility and security POV this is a nightmare and no one
should never ever trust such configure scripts

> Not using generated output is a good idea anyway and removes the
> requirement to trust that the release tarballs are faithful derivations
> from the autotools sources, but given the bland complexity of build system
> code (whether that's recursive Makefiles, CMake cruft, or the infamous
> gorilla spit[1] of autotools) I don't see a good way out.

I guess I miss the technical details about why it's not possible to
_always_ bootstrap the build system files from autoconf/automake
sources: do you have any reference documentation or technical article as
a reference, please?

> [1]
> https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#History

I'll study the autoconf history :-)

>> Given the above observation that «it is pragmatically impossible [...]
>> to peer review a tarball prepared in this manner», I strongly doubt that
>> a possible Makefile tampering _in_the_release_tarball_ is easy to peer
>> review; I'd ask: is it feaseable such an "automated analysis" (see
>> above) in a dedicated build-system phase?
>
> I don't think it's feasible.  Since Guix isn't a regular user (the
> target audience of configure scripts) it has no business depending on
> generated configure scripts.  It should build these from source.

Maybe I misunderstand your argument or, more probably, I was too
cryptic.  I mean, Someone™ is telling that moving the unpacking of the
backdoor object to a Makefile rule is an easy target for _automated_
analisys: is that someone wrong or is there a way to analyze a Makefile
to answer "Which files have 'special' rules?"

>> In other words: what if the backdoor was injected directly in the source
>> code of the *official* release tarball signed with a valid GPG signature
>> (and obviously with a valid sha256 hash)?
>
> A malicious maintainer can sign bad release tarballs.  A malicious
> contributor can push signed commits that contain backdoors in code.

Oh yes, but it's way more harder to hide backdoors in code published as
signed (signed?!?) commits in a DVCS.

Obviously no security system is perfect, but Some™ is (very) less
perfect than others. :-)

>> Do upstream developer communities peer review release tarballs or they
>> "just" peer review the code in the official DVCS?
>
> Most do neither.  I'd guess that virtually *nobody* reviews tarballs
> beyond automated tests (like what the GNU maintainers' GNUmakefile /
> maint.mk does when preparing a release).

I guess that in "nobody" are included Guix package contributors and
committers...  Then I'd say that virtually *nobody* should trust
tarball!  :-O

To be clear: I'm not suggesting that "tarball reviews" - that is, verify
the /almost/ exact correspondence of the tarball with the corresponding
DVCS commit - should be added as a requirement for contributors or
maintainers... it would be too burdensome.

>> Also, in (info "(guix) origin Reference") I see that Guix packages can have a
>> list of uri(s) for the origin of source code, see xz as an example [7]:
>> are they intended to be multiple independent sources to be compared in
>> order to prevent possible tampering or are they "just" alternatives to
>> be used if the first listed uri is unavailable?
>
> They are alternative URLs, much like what the mirror:// URLs do.

OK understood, thanks!

[...]

>> All in all: should we really avoid the "pragmatically impossible to be
>> peer reviewed" release tarballs?
>
> Yes.

I tend to agree! :-(

Thank you! Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature