Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122836
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------l609mjJj6emCHXKDaC2VU6di"
Message-ID: <972440f6-64b3-488e-be75-367532ba9d87@rwec.co.uk>
Date: Sun, 31 Mar 2024 16:36:48 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: internals@lists.php.net
References: <AM8P250MB01705B564C0F9B2F460F56B0E2392@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com>
 <3d90e236-49d8-4f80-a6dd-3584267a83e3@php.net>
 <586c3320-b38b-47bb-9c06-6762f1eb242b@gmail.com>
 <cc1e1415-a4cd-4bb2-99f0-e5b05ef6582c@gmail.com>
 <CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com>
 <1c7bcd0e-4e32-480f-acd2-2c8eb049bde2@gmail.com>
 <3E13B046-FE40-48D7-AAF0-13362B12C438@cschneid.com>
Content-Language: en-GB
In-Reply-To: <3E13B046-FE40-48D7-AAF0-13362B12C438@cschneid.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------l609mjJj6emCHXKDaC2VU6di
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 31/03/2024 14:53, Christian Schneider wrote:
> But my main question is: I fail to see the difference whether I plant my
>   malicious code in configure, configure.ac or *.c: Someone has to review
>   the changes and notice the problem. And we have to trust the RMs. What
> am I missing?


As I understand it, the attack being discussed involved*code that was never committed to version control*. The bulk of the payload was committed in fake binary test artifacts, which are unlikely to be inspected but harmless by themselves; but the trigger to incorporate it into the binary was added*manually*  in between the automated build and producing the signed release archive.

So the theory is that if there's no human involved in that process, there is no way for a human to introduce a malicious change at that step. An exploit would need to be introduced somewhere in version controlled, human-readable, code; giving extra chances for it to be detected.


On 30/03/2024 18:24, Jakub Zelenka wrote:
> Do you think it would be different if the change happened in the 
> distributed source file instead? I mean you could still modify tarball 
> of the distributed file (e.g. hide somewhere in configure.ac or in our 
> case more easily in less visible files like various Makefile.frag and 
> similar). The only thing that you get by using just VCS files is that 
> people could hash the distributed content of the files and compare it 
> with the hash of the VCS files but does anyone do this sort of 
> verification?


We already use a version control system built entirely on comparing hashes of source files. So given a signed tarball that claimed to match the content of a signed tag, any user can trivially check out the tag, expand the tarball, and run "git diff" to detect any anomalies.

The question of who would do that in practice is a valid one, and something that I'm sure has been discussed elsewhere regarding reproducible binary builds.



On 30/03/2024 15:35, Daniil Gentili wrote:
> Btw, I do not believe that "it would require end users to install 
> autotools and bison in order to compile PHP from tarballs" is valid 
> reason to delay the patching of a serious attack vector ASAP.


As is always the case, there is a trade-off between security and 
convenience - in this case, distributing something that's usable without 
large amounts of extra tooling (including, for some generated files, a 
copy of PHP itself), vs distributing something that is 100% reviewable 
by humans.

Ultimately, 99.999% of users are not going to compile their own copy of 
PHP from source; they are going to trust some chain of providers to take 
the source, perform all the necessary build steps, and produce a binary. 
Removing generated files from the tarballs doesn't eliminate that need 
for trust, it just shifts more of it to organisations like Debian and 
RedHat; and maybe that's a valid aim, because those organisations have 
more resources than us to build appropriate processes.

Making things reproducible aims to attack the same problem from a 
different angle: rather than placing more trust in one part of the 
chain, it allows multiple parallel chains, which should all give the 
same result. If builds from different sources start showing unexplained 
differences, it can be flagged automatically.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------l609mjJj6emCHXKDaC2VU6di
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 31/03/2024 14:53, Christian
      Schneider wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3E13B046-FE40-48D7-AAF0-13362B12C438@cschneid.com">
      <pre>But my main question is: I fail to see the difference whether I plant my
 malicious code in configure, configure.ac or *.c: Someone has to review
 the changes and notice the problem. And we have to trust the RMs. What 
am I missing?</pre>
    </blockquote>
    <p><br>
    </p>
    <pre class="moz-quote-pre" wrap="">As I understand it, the attack being discussed involved <b
    class="moz-txt-star"><span class="moz-txt-tag">*</span>code that was never committed to version control<span
    class="moz-txt-tag">*</span></b>. The bulk of the payload was committed in fake binary test artifacts, which are unlikely to be inspected but harmless by themselves; but the trigger to incorporate it into the binary was added <b
    class="moz-txt-star"><span class="moz-txt-tag">*</span>manually<span
    class="moz-txt-tag">*</span></b> in between the automated build and producing the signed release archive.

So the theory is that if there's no human involved in that process, there is no way for a human to introduce a malicious change at that step. An exploit would need to be introduced somewhere in version controlled, human-readable, code; giving extra chances for it to be detected.


</pre>
    <div class="moz-cite-prefix">On 30/03/2024 18:24, Jakub Zelenka
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEKnhAGm3xZJ_4MEjcQW+60TFSS5GjnppRQ9A9zCe9ehAgktvQ@mail.gmail.com">Do
      you think it would be different if the change happened in the
      distributed source file instead? I mean you could still modify
      tarball of the distributed file (e.g. hide somewhere in
      configure.ac or in our case more easily in less visible files like
      various Makefile.frag and similar). The only thing that you get by
      using just VCS files is that people could hash the distributed
      content of the files and compare it with the hash of the VCS files
      but does anyone do this sort of verification?</blockquote>
    <p><br>
    </p>
    <pre class="moz-quote-pre" wrap="">We already use a version control system built entirely on comparing hashes of source files. So given a signed tarball that claimed to match the content of a signed tag, any user can trivially check out the tag, expand the tarball, and run "git diff" to detect any anomalies.

The question of who would do that in practice is a valid one, and something that I'm sure has been discussed elsewhere regarding reproducible binary builds.



</pre>
    <div class="moz-cite-prefix">On 30/03/2024 15:35, Daniil Gentili
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1c7bcd0e-4e32-480f-acd2-2c8eb049bde2@gmail.com">Btw, I
      do not believe that "it would require end users to install
      autotools and bison in order to compile PHP from tarballs" is
      valid reason to delay the patching of a serious attack vector
      ASAP.</blockquote>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap"></span><span
      style="white-space: pre-wrap"></span><span
      style="white-space: pre-wrap">As is always the case, there is a trade-off between security and convenience - in this case, distributing something that's usable without large amounts of extra tooling (including, for some generated files, a copy of PHP itself), vs distributing something that is 100% reviewable by humans.</span></p>
    <p><span style="white-space: pre-wrap">Ultimately, 99.999% of users are not going to compile their own copy of PHP from source; they are going to trust some chain of providers to take the source, perform all the necessary build steps, and produce a binary. Removing generated files from the tarballs doesn't eliminate that need for trust, it just shifts more of it to organisations like Debian and RedHat; and maybe that's a valid aim, because those organisations have more resources than us to build appropriate processes.</span></p>
    <p><span style="white-space: pre-wrap">Making things reproducible aims to attack the same problem from a different angle: rather than placing more trust in one part of the chain, it allows multiple parallel chains, which should all give the same result. If builds from different sources start showing unexplained differences, it can be flagged automatically.</span></p>
    <pre class="moz-quote-pre" wrap="">

Regards,
</pre>
    <p></p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------l609mjJj6emCHXKDaC2VU6di--