Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122829 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E654C1A009C for ; Sat, 30 Mar 2024 17:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711820792; bh=WM3iuKfPq9A6dEFHgmdGZdSJm4mpWJNR0LIY2VPZfYk=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=OKdcqZwIgxhWLEna+/IYWdt866kGoDt2JSqCWktXLACKPPxWgTN3nrC1IvJb1AS88 JXk7/JGCznWS09RVKf65JJgoB0g46fqDubJ0DvKwx5abQiE2fHFzaqI2mBM4C+4N3o 0VKY3yokdwjUGiStVV9A83fLbSwt+7muEX+YOXiUa+Q4CcMGkm9DLmEybwrF/5WCnQ ekf0smxizZFfalAnogqEJE5aE+ZRK0cjSJW+hjE5LlkXeHnuluwQZhMBxX6QPW4BTu BPpr880F6iXTTkrelim+B2cfxbdrQmSh7hGP041PhGPqvIkgLQiAyyHhItD7niX/S7 ofqZZjrArK22g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B82DE180074 for ; Sat, 30 Mar 2024 17:46:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MIME_QP_LONG_LINE,MPART_ALT_DIFF, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f196.google.com (mail-yw1-f196.google.com [209.85.128.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 30 Mar 2024 17:46:29 +0000 (UTC) Received: by mail-yw1-f196.google.com with SMTP id 00721157ae682-6143c158b95so14346217b3.1 for ; Sat, 30 Mar 2024 10:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benramsey.com; s=google; t=1711820762; x=1712425562; darn=lists.php.net; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=caOgcxX48zikHIJb3fn5DCRvYjEzRzWHnVNxfGaIiI0=; b=cS0+BsjEXdB/MONWszxfHS0xwf3q0sWSUSQK3yNDLACGHpO5eKlh7jAljkmFT0ZQIJ AqBfY40BGZFBT5PSkuT2+iu+du6iCimhswZwZ78oeEmPOmrd5EWf4ltxESOMCAExIE6R riB8GNXEKo/IrBeXKWKQVh971vkgvN9yaNCJX1US1X9PrAdBKp3sGpASVJw0m7DP74xx MsEH7wBJYPT5AK7lqLoLpckx00nhUyuwhCdqpEpeR2VyE/5dZKCqLNRJ9pmK4KdhYlbe ekQ7H4g1FV4tt1Ae8Q+B5zZn4HwRnoNw6sSd/tZmVUmeJj+/IEuwpR3imqNwHERZPhtq z/lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711820762; x=1712425562; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=caOgcxX48zikHIJb3fn5DCRvYjEzRzWHnVNxfGaIiI0=; b=iD0Dj8EhRDiSDwJqan48YiAWvsLxzN22W0obGtnCE1IIX4HomFdsoOuHqlBZB9VjOX ceisN1E4sNYDXQM+jKBgoohzBCfOV/iE5WRTgNRkEi2VwWXz+PDyOqhIiUPa5lj4kpr3 Z/NEAEFjk5M8jYzODLyL9qRrqNQsBXCYlE1AQEVrVydK2AOcNb6xkKKWugYgxxj9mpai YSGTc1gt4/8PSV0QctzFQEtCIkNwSiXoKqLbobGRXo8+BIZmXqpk3hBPGTE2s52xdCPr FzBTsiyv+dL3KYVEk4hMhh2TPdym30+Lq2Du04rsiTxwseNgFWNokOOmmeltzjirRoIG RNxg== X-Forwarded-Encrypted: i=1; AJvYcCXHVQycH0bd71bZot3K3+ou8FZoGF8M4jVU3rldlKLmq7lhl1CvNnC5nd/jWrkxb803z3qoCcVd8VL5GXDBYcdQuFBQ5c3/sg== X-Gm-Message-State: AOJu0Ywc1lqUlOzi173DYuajv+AtxOLCZ3znvO9x4JADSEWdJ/UXHMnK rTpZ+gkUapEq2E8pv4l79SAVDJ6kCugDidJgfWAMUitZa4MfHwsc+tNGTY9Xag== X-Google-Smtp-Source: AGHT+IHa5O4l9qngOF48A6DRDpLD6iifrgHURbGmaRQW0MmZO0/zW5MoBnnhIN8SlZiKEZfGbdcaLQ== X-Received: by 2002:a81:d302:0:b0:614:7f18:3856 with SMTP id y2-20020a81d302000000b006147f183856mr1083364ywi.8.1711820761697; Sat, 30 Mar 2024 10:46:01 -0700 (PDT) Received: from smtpclient.apple (h96-61-170-179.lvrgtn.broadband.dynamic.tds.net. [96.61.170.179]) by smtp.gmail.com with ESMTPSA id l73-20020a81574c000000b00614a10acdc4sm76679ywb.42.2024.03.30.10.46.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Mar 2024 10:46:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C425B968-46EF-4300-9820-DD66AF434C04 Content-Transfer-Encoding: 7bit Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (1.0) Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs Date: Sat, 30 Mar 2024 12:45:49 -0500 Message-ID: References: Cc: Marco Pivetta , Bob Weinand , Daniil Gentili , PHP Internals List In-Reply-To: To: Jakub Zelenka X-Mailer: iPhone Mail (21D61) From: ben@benramsey.com (Ben Ramsey) --Apple-Mail-C425B968-46EF-4300-9820-DD66AF434C04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
= On Mar 30, 2024, at 07:03, Jakub Zelenka <bukka@php.net> wrote:
=EF=BB=BF
Hi,

On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta &l= t;ocramius@gmail.com> wrote:


= On Sat, 30 Mar 2024, 05:19 Ben Ramsey, <ben@benramsey.com> wrote:
On Mar 29, 2024, at 20:20, Bob Weinand <bobwei9@hotm= ail.com> wrote:

<= div dir=3D"ltr">=EF=BB=BF =20 =20
On 29.3.2024 23:31:26, Daniil Gentili wrote:
=20 =20 In light o= f the recent supply chain attack in xz/lzma, leading to a backdoor in openSSH (https://www.openwall.com/lists/oss-se= curity/2024/03/29/4), I believe that it would be a good idea to remove the huge attack surface offered by the pre-generated autoconf build scripts and lexers, offered in the release tarballs.

In particular, the xz supply chain attack injected the exploit with a few obfuscated lines, manually added to the end of the pre-generated configure script, that was only bundled in the tarballs.

Even if t= he exploits themselves were committed to the repo in the form of test files, the code that actually injected the exploit in the library was not committed to the repo, and was only present in the pre-generated configure script in the tarball: this injection mode makes sense, as extra files in the tarball not present in the git repo would raise suspicions, but machine-generated configure scripts containing hundreds of thousands of lines of code not present in the upstream VCS are the norm, and are usually not checked before execution.

Specifica= lly in the case of PHP, along from the configure script, the tarball also bundles generated lexer files which contain actual C code, which is an additional attack vector, i.e. here's the diff between the tarball of the 8.3.4 release, and the PHP-8.3.4 tag on the git repo:

```
~ $ diff -= r php-8.3.4 php-src -q
Only in php-src: .git          &nbs= p;            &n= bsp;            =             &nbs= p;     Files php-8.3.4/NEWS and php-src/NEWS differ          &n= bsp;            =         Files php-8.3.4/Zend/zend.h and php-src/Zend/zend.h differ      &n= bsp;          Only in php-8.3.4/Zend: zend_ini_parser.c
Only in php-8.3.4/Zend: zend_ini_parser.h
Only in php-8.3.4/Zend: zend_ini_parser.output       &nbs= p;            &n= bsp;        Only in php-8.3.4/Zend: zend_ini_scanner.c
Only in php-8.3.4/Zend: zend_ini_scanner_defs.h
Only in php-8.3.4/Zend: zend_language_parser.c       &nbs= p;            &n= bsp;        Only in php-8.3.4/Zend: zend_language_parser.h       &nbs= p;            &n= bsp;        Only in php-8.3.4/Zend: zend_language_parser.output
Only in php-8.3.4/Zend: zend_language_scanner.c
Only in php-8.3.4/Zend: zend_language_scanner_defs.h      &nbs= p;            &n= bsp;   Only in php-8.3.4: configure          = ;            &nb= sp;            &= nbsp;           Files php-8.3.4/configure.ac and php-src/configure.ac differ          &n= bsp;    Only in php-8.3.4/ext/json: json_parser.tab.c        &nb= sp;            &= nbsp;        Only in php-8.3.4/ext/json: json_parser.tab.h
Only in php-8.3.4/ext/json: json_scanner.c
Only in php-8.3.4/ext/json: php_json_scanner_defs.h       &nb= sp;            &= nbsp;   Only in php-8.3.4/ext/pdo: pdo_sql_parser.c
Only in php-8.3.4/ext/phar: phar_path_check.c        &nb= sp;            &= nbsp;        Only in php-8.3.4/ext/standard: url_scanner_ex.c
Only in php-8.3.4/ext/standard: var_unserializer.c
Only in php-8.3.4/main: php_config.h.in
Files php-8.3.4/main/php_version.h and php-src/main/php_version.h differ   Only in php-8.3.4/pear: install-pear-nozlib.phar       &n= bsp;            =        Only in php-8.3.4/sapi/phpdbg: phpdbg_lexer.c         =             &nbs= p;        Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.c         = ;            &nb= sp;       Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.h
Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.output
```

To preven= t attacks from malevolent/compromised RMs, I propose completely removing all autogenerated files from the release tarballs, and ensuring their content exactly matches the content of the associated git tag (this means also removing the -dev prefix from the version number in main/php_version.h, Zend/zend.h, configure.ac and NEWS in the git tag).

Of course= this means that users will have to generate the build scripts when compiling PHP, as when installing PHP from the VCS repo.=

I'm sendi= ng a copy of this email to security@php.net as well.

Hey Daniil,

You can also have a public CI (i.e. a github action) generate the artifacts, along with hash computation.
It should be a github action which runs on tags. This makes it fully verifiable; i.e. the code for the generation of action, including the hash. Anyone who wants can trivially trace this back.

There's nothing in the tarballs which cannot be trivially automated and made verifiable.

I don't think providing pre-generated files is fundamentally flawed, the primary lacking thing is verifiability. Which is also what enabled the xz backdoor.

Bob

=20

This is also why our release managers sign the t= arballs with their own GPG keys, after generating the artifacts. This verifi= es the release manager was the one who generated the files.

Cheers,
Ben

Hey Ben,

I understand that the XZ project had signed releases too:= that still means that downstream consumers would need to trust the release m= anagers anyway, and reproduce the whole chain themselves.

I suppose that's part of OP's concern.


I agree t= hat compromised RM is a problem that we should look into.

We have been actually already discussing something similar. I have be= en thinking about it and it could be potentially used for all builds. The id= ea is that we would setup worklfow on CI that would run on tag push and it w= ould call (authenticated https request) downloads.php.net server that could do the actual build, sign them and r= eturn the hashes to the CI job which would display them and do extra verific= ation (probably its own build to verify that download server work as expecte= d). Then the builds would be made available for download. The RM job would b= e just to check that everything worked as expected, potentially verify that t= he builds for download and do all the announcements. This is a bit of work t= o do but I think it should then completely remove the possibility of comprom= ised RM to compromise the builds which is currently possible. It would proba= bly makes sense to let RM to sign the builds as well which should then reduc= e chance of downloads server being compromised.

It n= eeds more thinking to iron out all details and make sure it is a secure but I= think it would be something worth to look at.

Rega= rds

Jakub
=
I worked on a PR that would move the entire build process to C= I, and I had it working, but at the time, it was regarded as an anti-pattern= and security risk to sign the builds on CI servers.

All that work is here, in case you want to refer to it: https://github.com/php/php-src/pull= /10604

Cheers,
Ben

= --Apple-Mail-C425B968-46EF-4300-9820-DD66AF434C04--