Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120814 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23857 invoked from network); 14 Jul 2023 02:08:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Jul 2023 02:08:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 57BFB180339 for ; Thu, 13 Jul 2023 19:08:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS63949 74.207.240.0/20 X-Spam-Virus: No X-Envelope-From: Received: from malamute.woofle.net (woofle.net [74.207.252.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 13 Jul 2023 19:08:56 -0700 (PDT) Received: by malamute.woofle.net (Postfix) with ESMTPSA id 67A071F18D; Thu, 13 Jul 2023 19:08:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) In-Reply-To: Date: Thu, 13 Jul 2023 19:08:44 -0700 Cc: Sergii Shymko , "internals@lists.php.net" Content-Transfer-Encoding: quoted-printable Message-ID: <57CF1A83-4861-4AE0-92D4-5724A40A00D0@woofle.net> References: To: David Gebler X-Mailer: Apple Mail (2.3731.600.7) Subject: Re: [PHP-DEV] Security implications of parsing env variables in .ini From: dusk@woofle.net (Dusk) On Jul 13, 2023, at 18:34, David Gebler wrote: > If you find any way to exploit this, you've already breached enough to > have sufficient access to read the entire environment available to the = PHP > user anyway I think Sergii's concern is that an application might be using = parse_ini_string() to transform user-provided string data into an array, = and that it might not expect environment variables to be expanded in = this context. IMO, this is a valid concern, and: 1) Expansion of environment variables and php_ini settings needs to be = mentioned more prominently in the documentation for parse_ini_string() = and parse_ini_file(), with an explicit caution against using the = functions on untrusted input. 2) These expansions should probably be disabled by INI_SCANNER_RAW; that = flag already disables certain other types of value interpolation. = (Oddly, it doesn't disable expansion of constants either; that might be = worth revisiting as well.)=