unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: rain1@openmailbox.org
To: Guix Devel <guix-devel@gnu.org>
Subject: The waf problem (running nondeterministic binary blobs at build)
Date: Mon, 25 Apr 2016 14:20:13 +0100	[thread overview]
Message-ID: <4a18bcd6782d6dd053be5bc1c732a525@openmailbox.org> (raw)

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.

             reply	other threads:[~2016-04-25 13:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 13:20 rain1 [this message]
2016-04-26 10:16 ` The waf problem (running nondeterministic binary blobs at build) Ludovic Courtès
2016-04-30 23:55   ` Alex Griffin
2016-05-01 13:25     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a18bcd6782d6dd053be5bc1c732a525@openmailbox.org \
    --to=rain1@openmailbox.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).