The waf problem (running nondeterministic binary blobs at build)

The waf problem (running nondeterministic binary blobs at build)

[rain1]

Hello

I think there is a danger in packaging programs that use the 'waf' build 
system. That may pass a regular source code audit.

If you look at the last line of a waf file you may see strange text like 
this:

#==>
#BZh91AY&Ha<F0><<F7><FB>n<F6>l^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^O^GL^U...
#<==

It looks exactly like a PHP backdoor e.g. 
<https://www.trustwave.com/Resources/SpiderLabs-Blog/Hiding-Webshell-Backdoor-Code-in-Image-Files/>

Now waf is not malicious, it is actually an encoded bzip file containing 
the waf build system python scripts, the waf script reads its own source 
code and unpacks that before loading and running it.

but I don't think the authenticity of these scripts is being verified, 
since they are not being looked at and are obfuscated they are the 
perfect vector to hide a malicious code/backdoor.

Hoping to see if any specific ones had been tampered or that they were 
all equal I checked the sums of the files:

SHA256 (./ardour/waf) = 
205a55cfcbb5e54a70136f7cea2413c7de8a12e69d76cb56eec7d995ff06c44d
$ sha256 ./samba-4.3.8/buildtools/bin/waf
SHA256 (./samba-4.3.8/buildtools/bin/waf) = 
da076fbe7e5a9415035185fc19ab15a26ad3df5486181c25f9117c9ac32a9389
$ sha256 ./samba-4.3.8/third_party/waf
SHA256 (./samba-4.3.8/third_party/waf) = 
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
$ sha256 ./jalv-1.4.6/waf
SHA256 (./jalv-1.4.6/waf) = 
71b3c875adc31c5bf2c5c22eee3efc6da960be90c65ac56dfa0ae6e02cc64201
$ sha256 ./aubio-0.4.1/waf
SHA256 (./aubio-0.4.1/waf) = 
a71e5c6bd78ddd5cc9c15d7391921a23ca1c2ab4b2f9a56c9fad08f93cf23771

All of them are different! I think the bzip data is being created in 
non-reproducible way. This provides extra cover for malicious code and 
is a problem for auditing.

There are signed waf files that can be gpg verified <https://waf.io/>, 
but they are not being used.

I noticed that the mpv package actually copies a waf file in from the 
waf build system instead of using a packaged one, but (like others) it 
includes a waftools tree of python scripts. Maybe a policy like that 
would be a good response (rejecting included waf with binary blobs in 
them and checking that included build scripts are safe).

Anyway I hope this information is useful to improving the security of 
guix. Whatever way you decide to address it.

Re: The waf problem (running nondeterministic binary blobs at build)

[Ludovic Courtès]

Hi!

rain1@openmailbox.org skribis:

> I think there is a danger in packaging programs that use the 'waf'
> build system. That may pass a regular source code audit.
>
> If you look at the last line of a waf file you may see strange text
> like this:
>
> #==>
> #BZh91AY&Ha<F0><<F7><FB>n<F6>l^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^O^GL^U...
> #<==

Ouch.

> Now waf is not malicious, it is actually an encoded bzip file
> containing the waf build system python scripts, the waf script reads
> its own source code and unpacks that before loading and running it.

In a way this is similar to Autoconf-generated ‘configure’ scripts, only
more “concealed.”

One could argue that this is source, in the form of a self-extracting
archive, but source anyway.

We could regenerate the ‘waf’ script of all Waf-using packages instead
of using the provided one.  However, we risk encountering
incompatibilities, which is probably one of the reasons why Waf does
this.

But we would need to apply the same reasoning to
Autoconf/Automake-generated files; this is what Debian does, but it
would defeat the whole purpose of these tools, which is to facilitate
bootstrapping by requiring nothing more than a Bourne shell and ‘make’.

> but I don't think the authenticity of these scripts is being verified,
> since they are not being looked at and are obfuscated they are the
> perfect vector to hide a malicious code/backdoor.

As for all packages, packagers should check the authenticity of the
tarball that contains the ‘waf’ script.

There is still the possibility, though, that the developer who produced
the tarball was themself a victim of a targeted attack that led them to
introduce a backdoored ‘waf’ into the tarball.  But the same could be
said of Autoconf, I suppose.

Thoughts?

Ludo’.

Re: The waf problem (running nondeterministic binary blobs at build)

[Alex Griffin]

Debian replaces all binary 'waf' files with their own
'waf-uncompressed'. I think our python-waf package should be altered to
produce an uncompressed version, then the waf-build-system should
automatically use that (look at the python-pycairo package for an
example of using the system's waf version instead of the bundled one).
-- 
Alex Griffin


On Tue, Apr 26, 2016, at 05:16 AM, Ludovic Courtès wrote:
> Hi!
> 
> rain1@openmailbox.org skribis:
> 
> > I think there is a danger in packaging programs that use the 'waf'
> > build system. That may pass a regular source code audit.
> >
> > If you look at the last line of a waf file you may see strange text
> > like this:
> >
> > #==>
> > #BZh91AY&Ha<F0><<F7><FB>n<F6>l^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^O^GL^U...
> > #<==
> 
> Ouch.
> 
> > Now waf is not malicious, it is actually an encoded bzip file
> > containing the waf build system python scripts, the waf script reads
> > its own source code and unpacks that before loading and running it.
> 
> In a way this is similar to Autoconf-generated ‘configure’ scripts, only
> more “concealed.”
> 
> One could argue that this is source, in the form of a self-extracting
> archive, but source anyway.
> 
> We could regenerate the ‘waf’ script of all Waf-using packages instead
> of using the provided one.  However, we risk encountering
> incompatibilities, which is probably one of the reasons why Waf does
> this.
> 
> But we would need to apply the same reasoning to
> Autoconf/Automake-generated files; this is what Debian does, but it
> would defeat the whole purpose of these tools, which is to facilitate
> bootstrapping by requiring nothing more than a Bourne shell and ‘make’.
> 
> > but I don't think the authenticity of these scripts is being verified,
> > since they are not being looked at and are obfuscated they are the
> > perfect vector to hide a malicious code/backdoor.
> 
> As for all packages, packagers should check the authenticity of the
> tarball that contains the ‘waf’ script.
> 
> There is still the possibility, though, that the developer who produced
> the tarball was themself a victim of a targeted attack that led them to
> introduce a backdoored ‘waf’ into the tarball.  But the same could be
> said of Autoconf, I suppose.
> 
> Thoughts?
> 
> Ludo’.
> 

Re: The waf problem (running nondeterministic binary blobs at build)

[Ludovic Courtès]

Alex Griffin <a@ajgrf.com> skribis:

> Debian replaces all binary 'waf' files with their own
> 'waf-uncompressed'. I think our python-waf package should be altered to
> produce an uncompressed version, then the waf-build-system should
> automatically use that (look at the python-pycairo package for an
> example of using the system's waf version instead of the bundled one).

Sounds like a plan.  We can take this route and adjust if we stumble
upon incompatibilities.

Apparently we’d have 20 packages to audit:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,use(gnu)
scheme@(guile-user)> ,use(guix build-system waf)
scheme@(guile-user)> (fold-packages (lambda (p n)
				      (if (eq? (package-build-system p) waf-build-system)
					  (1+ n)
					  n))
				    0)
$2 = 20
--8<---------------cut here---------------end--------------->8---

We can do that incrementally, and patches going in that direction would
be welcome!

Thanks for your feedback,
Ludo’.