Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115019 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51339 invoked from network); 22 Jun 2021 11:07:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2021 11:07:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 01C5B1804D9 for ; Tue, 22 Jun 2021 04:25:23 -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=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jun 2021 04:25:22 -0700 (PDT) Received: by mail-ej1-f50.google.com with SMTP id hc16so5605780ejc.12 for ; Tue, 22 Jun 2021 04:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:from:to:cc:subject:in-reply-to:references :user-agent:message-id:content-transfer-encoding; bh=v8IhIlOYhHGp1VqQCuRDXKhN8hv3tML0zzUv2guo70U=; b=FApgct8FSXO5G/NPET2kcvTzD3Q6jt7G/v0/xPFK/aIbjcpYQsfNxaEYKL6xJDDb4s 4ndEsC37IK9/mGth443xp7hxUAtT/1MhWRjzKIPaUOFyN79RCXDzJg2x+PdZUpKURrYC 9TVl/o9O50vlfDZqBKo+C1lGVDoJ+qu2yGdr3g16/JVYA15vhod+DjAgidAnac6OnFzt Y+Go8wbkbtoMGaxZpIvQmpGOIyUsbpINHqJbPxiqWReNu9nQnRXfRDzyG/iRi4l5k8yG oV2ZENqpqn634hU2f+b6ndf7k7cTJArm2RIupaisvT7Drf8CQNVLKUYzaPmXJusqxexk 8vZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:from:to:cc:subject:in-reply-to :references:user-agent:message-id:content-transfer-encoding; bh=v8IhIlOYhHGp1VqQCuRDXKhN8hv3tML0zzUv2guo70U=; b=a8N4QFeQhd3CEyCjpbGSl21L45YAPzbX95K2lUjsboKz1BXsWyf8o/BgxounkZqJY1 UCPBMO3XR4wuilvSoHaETFCJhtH1FkOgcmC5Pwe932N3x5K0sr5niY7Gmc9Ew992cQU6 HkTk7gEfRB0Nt8n3awqP8q+guJli8mIDNVbEehbhwxsWQDLIzJb2BviA97zpZiCWjn8H 1xuSEx3ZQMu8fQ0T/7kTFIG6qserQg9I6htf2mLhqmCjiY7srMZqBZz9NOsN/WaH8ps7 R/5+Pmu9GJLA5WdX1ic1ihAkZVi0+jAUOVxc/yN4ks9RL74q/uSyNqErZXbOEz/zOv82 sS/A== X-Gm-Message-State: AOAM532mUQ2o0nBrf3phKHPr1E6TZBo6uElIx4fqFND+GQipU7vtexrL 6rhNjEBgzm0bTnPx97rwT4c= X-Google-Smtp-Source: ABdhPJy4FrqCX2eRgkpHMEx7+8HmL2qVjPQs+qq4IO8Hd1s2MUS1/RGfJxBw9QlnfVKhzQCP1ZmNfQ== X-Received: by 2002:a17:906:52d5:: with SMTP id w21mr2179304ejn.490.1624361121206; Tue, 22 Jun 2021 04:25:21 -0700 (PDT) Received: from k-piste.fi (k-piste.fi. [95.179.136.7]) by smtp.gmail.com with ESMTPSA id u17sm6158708edt.67.2021.06.22.04.25.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jun 2021 04:25:20 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 22 Jun 2021 14:25:19 +0300 To: Joe Watkins Cc: Claude Pache , Craig Francis , PHP internals In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.11 Message-ID: <1229f71be88401d9eb55a212f53e3eae@gmail.com> X-Sender: lauri.kentta@gmail.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] is_literal From: lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=) On 2021-06-15 10:19, Joe Watkins wrote: > It's just that existing implementation details - RETURN_CHAR using > interned > strings, and literal constant strings being interned by the compiler - > lead > to a literal string being "re-used". > > This is just a natural consequence of literal strings retaining their > literalness in the way we want them too, nothing dangerous is going on. This happens with substr as well, even with user input. With just one character, the possibilities are rather limited, but still I'm sure someone finds a way to turn this into a vulnerability. Such as: $c = substr($input, 0, 1); # $c is now literal. $sql = "SELECT * FROM t WHERE c LIKE '$c%'"; Hopefully this "retaining literalness" does not extend to longer strings after any operations. What about Opcache? A few years back I debugged some interning-related bugs which only manifested with Opcache, so I'm just thinking maybe there's some way to exploit Opcache to make some string interned under special circumstances, and just maybe that string can then be accidentally reused in a SQL query. I'm not in the mood to dive into Opcache internals to check this, so I hope someone with prior knowledge can tell what kind of strings get interned by Opcache. Array keys? Object properties? -- Lauri Kenttä