Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122681 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 ED3CA1AD8F6 for ; Mon, 18 Mar 2024 12:25:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1710764742; bh=zy1JoIw/lASMwJ7mglqQM8sCOa0DuaiCzZV7/O2HvwE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LmsD/WmZriBl9ZGPkQKGlB4tf00Nv+r1rfiKP75IdW4oLzIvg3ODDGGRHxSLRDxis sPkROeYq3f3Q+BeHSp3k1efTjspvm9FRKp4aLXgFncfN2sA8pGNsK4WomwaKVEyvzn WjabYm/tbRn2zPrPSFnnxGBZrpx4pdQk+GTDNh9enC9peqvOeAgWwB6GcRqE+lCg2X czWwn/YJk+FpUtGO8pHWTxPHExM8ZGRZEXatuvU7d7WnEJ9/+BMukkM7wJC3VkLubN +2eP134HqpE2Ku6Lb3zFazRob3YIVUwFIXQHPB3HmypQtgws1/MzrWp5cUwYODyYPb MICGWNBt7H9kA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6B666180628 for ; Mon, 18 Mar 2024 12:25:41 +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=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, 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-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 X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 18 Mar 2024 12:25:37 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a4682272ff6so324796166b.2 for ; Mon, 18 Mar 2024 05:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710764717; x=1711369517; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zy1JoIw/lASMwJ7mglqQM8sCOa0DuaiCzZV7/O2HvwE=; b=Jq1qqm2A6LYV7uo8lRM2LbAsFGIhGGfwa+jomWLV71cmmf3jpcykrkApPqWeeFBrGC Z4uWacnHSAxr8lDQhTVqSxnMrIlWUwhPsdoDyw3DwkWbQfFzwsu1P1R2d2rxwjPzjHT+ d3fhIPdrezRlKnXXxUXXEWTfh+JA+/Q/Kv3/MekMiVW4CuE5AOFtCJIPvT4FV7VEuv8C K8vHpj7P9CP4g/fyNJMvwplxNp8MAM95zBLTsF5cVgR7IFBDAR3jYoVvTHdcniTLG0lh wVjqLZCeRQdUuzWpEXbkHAWkhdbeezCR+hpDDz+4ffVzHTHWaQcfSyJSG9KgBuNHkvT6 UmfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710764717; x=1711369517; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zy1JoIw/lASMwJ7mglqQM8sCOa0DuaiCzZV7/O2HvwE=; b=TtaAgSJ+z2jiW3M1qv0VPzWtHkdXNDyJFV0bDF/bnwzO8nohL69s/fDFEKYdOQvbLd F4gLEoz/2TBfaO93HYTgPI/iDSpob9AUBQEJTZX9tu0xgCenvZ55TwHbfqTw41DOps71 VDmKAI7DzxfIfYu1uxN31ymXzBSCradKnXDh63vaRkLABXCFYw5s+NOrIQaz8VpRLKYS n5PHOkXE+Mv7wDc2kwDFZOOihTLwuk+fG06iC9xGBTsNUi/8r3OIXYeM+RJDG0QJf/x1 Rabt9vcLZhGVfZ72+r/VRCsdxTxvtS1mknhlX23SGr/1tstrvs3pu8/Q/hafFAzF6AWM 4y1g== X-Gm-Message-State: AOJu0Yy/8nUr77nWefwj028Xjy1Tk6Ra598XUJgzwEV3gp0qfRKtRfia gEpaq7WFkC3/M+mLhqdWOzvigBYOvbKOZvAo5ZjI9PJTalQ9LXOrlGLDK2fvgbFoX64EQJyrM22 Qkkm2y645LM26nCsxJF1MdZy9VmOTNPuRQIk= X-Google-Smtp-Source: AGHT+IEeo+FlySiMKNoYLy17xCmYC4ZplY+bSqLkXaS5R6SX0s9MKYu4pjzTwKtiGJk7MB242NV3ipGC988fpaH9e1s= X-Received: by 2002:a17:906:35ca:b0:a46:c774:b99f with SMTP id p10-20020a17090635ca00b00a46c774b99fmr1140956ejb.48.1710764716748; Mon, 18 Mar 2024 05:25:16 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 18 Mar 2024 13:25:05 +0100 Message-ID: Subject: Re: [PHP-DEV] XSLTProcessor recursion limit To: Niels Dossche Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000003c77940613ee73ee" From: arnaud.lb@gmail.com (Arnaud Le Blanc) --0000000000003c77940613ee73ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Niels, On Sat, Mar 16, 2024 at 5:49=E2=80=AFPM Niels Dossche wrote: > Hi internals > > Based on https://bugs.php.net/bug.php?id=3D71571 I've opened a PR to > implement two new properties for XSLTProcessor: maxTemplateDepth and > maxTemplateVars. The reasoning behind this is that large templates with > lots of recursion and/or variables can bump against the default recursion > limit set by the libxslt library. > > PR link: https://github.com/php/php-src/pull/13731 > > I used an adapted version of > https://github.com/nikic/popular-package-analysis to download every > package that satisfies the search term "xsl". Then I checked if there are > any classes that extend XSLTProcessor and have the maxTemplateDepth or > maxTemplateVars field. > None do, and as such no package in packagist will observe a BC break > because of this PR. > > One sad detail however, is that you can set the recursion limit so high > that you can exhaust the stack space, which will crash the process with a > segfault. In fact, you can hit this already right now without the PR, usi= ng > XSL. I.e. you can create a very deep VM re-entry that won't cause the sta= ck > limit protection to kick in, and then start a recursive XSL template > processing that does not hit XSL's limit, but exhausts the remaining stac= k > space. Note that as soon as you do callbacks however, the stack limit > protection _will_ kick in. > I tried to check if it's possible to prevent this, but the stack limit > check would need to happen inside the libxslt library, so I don't think > it's possible. > > Let me know if there are any complaints about this. If no complaints, I'l= l > merge this in 2 weeks or so. > > Kind regards > Niels > For PCRE there is a pcre.recursion_limit setting [1] with the same issue. This is fine because that's a convenience feature (not a security one) and it is useful by catching most cases of uncontrolled recursion in practice. The default value is not changed by this PR (so there is no risk of BC break by lowering the limit), and appears to be low enough to prevent stack exhaustions on a default 2MiB stack on Linux. +1 for this [1] https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-lim= it Kind regards, Arnaud --0000000000003c77940613ee73ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Niels,

On Sat, Mar 16, 2024 at 5:49= =E2=80=AFPM Niels Dossche <do= ssche.niels@gmail.com> wrote:
Hi internals

Based on https://bugs.php.net/bug.php?id=3D71571 I've= opened a PR to implement two new properties for XSLTProcessor: maxTemplate= Depth and maxTemplateVars. The reasoning behind this is that large template= s with lots of recursion and/or variables can bump against the default recu= rsion limit set by the libxslt library.

PR link: https://github.com/php/php-src/pull/13731

I used an adapted version of https://github.com/nik= ic/popular-package-analysis to download every package that satisfies th= e search term "xsl". Then I checked if there are any classes that= extend XSLTProcessor and have the maxTemplateDepth or maxTemplateVars fiel= d.
None do, and as such no package in packagist will observe a BC break becaus= e of this PR.

One sad detail however, is that you can set the recursion limit so high tha= t you can exhaust the stack space, which will crash the process with a segf= ault. In fact, you can hit this already right now without the PR, using XSL= . I.e. you can create a very deep VM re-entry that won't cause the stac= k limit protection to kick in, and then start a recursive XSL template proc= essing that does not hit XSL's limit, but exhausts the remaining stack = space. Note that as soon as you do callbacks however, the stack limit prote= ction _will_ kick in.
I tried to check if it's possible to prevent this, but the stack limit = check would need to happen inside the libxslt library, so I don't think= it's possible.

Let me know if there are any complaints about this. If no complaints, I'= ;ll merge this in 2 weeks or so.

Kind regards
Niels

For PCRE there is a pcr= e.recursion_limit=20 setting [1] with the same=20 issue. This is fine because that's a convenience feature (not a=20 security one) and it is useful by catching most cases of uncontrolled recur= sion in=20 practice.

The default value is not changed by = this PR (so there is no risk of BC break by lowering the limit), and appear= s to be low enough to prevent stack exhaustions on a default 2MiB stack on = Linux.

+1 for this

=C2=A0
Kind regards,
Arnaud
=C2=A0
--0000000000003c77940613ee73ee--