From mboxrd@z Thu Jan 1 00:00:00 1970 From: rain1@openmailbox.org Subject: The waf problem (running nondeterministic binary blobs at build) Date: Mon, 25 Apr 2016 14:20:13 +0100 Message-ID: <4a18bcd6782d6dd053be5bc1c732a525@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1augRI-0005WC-T7 for guix-devel@gnu.org; Mon, 25 Apr 2016 09:20:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1augRE-0002ED-Qo for guix-devel@gnu.org; Mon, 25 Apr 2016 09:20:36 -0400 Received: from smtp1.openmailbox.org ([62.4.1.35]:38352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1augRE-0002Dq-Hw for guix-devel@gnu.org; Mon, 25 Apr 2016 09:20:32 -0400 Received: from www.openmailbox.org (openmailbox-b1 [10.91.69.218]) by mail2.openmailbox.org (Postfix) with ESMTP id 43B1A2AC735B for ; Mon, 25 Apr 2016 15:20:14 +0200 (CEST) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Guix Devel 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<nl^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^O^GL^U... #<== It looks exactly like a PHP backdoor e.g. 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 , 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.