Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107860 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51952 invoked from network); 26 Nov 2019 17:57:45 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 26 Nov 2019 17:57:45 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 9E11A2D1FBA for ; Tue, 26 Nov 2019 07:52:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 26 Nov 2019 07:52:26 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id l5so4548069vkb.4 for ; Tue, 26 Nov 2019 07:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Se5emakmzq7n8mdciroP1APM7mjDE/bgvKFnB4Z4QUk=; b=gZ4Bks6KPw0xYJ/lh7iwWqfsLevCVyHT+RJfFwBwF3oX61SYLJCYJG6Qw3qwqQ5di9 i8T5qCph+psNdg7FU8HbqJSKVDC1WaCyT7Z7Lg/WkjQX528p8k0+UJD5gFhnBg44Knl3 00yY/ZSYjRk5RcKuZ1Ugr+FhblKpz0DsSasCBcFYyNXM7AZnFHA8Mm158tYY5kADeAJ5 z92t4htPQqemIyE/9FihBiMgc2XZFtAFvN32bDgPGyQIu+Fa7n+/0rJJLWe3Glsa5JjE wzNv0xpsp7XX4hfmAW/dnVKuIeWDrqKudLTtFGP9TRh/iJCk4qSOjIl/8NvQuR8t4nM3 7zjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Se5emakmzq7n8mdciroP1APM7mjDE/bgvKFnB4Z4QUk=; b=Ma3ckvwmFrT0orgCP/NjZbBmFNExixSnW252bqvLDWcBPLj1JuyQCiXUo7a1rbeZ7T gZMGQeTOwu4cqJgQQCjwXZnkab/Pn8OtA5HFTWLLOLEyzzr2XMX3tfyy+2yjAotfrmD3 ifQUXJh8S2iyPf/vE5EGNctSUMbCzj7TkJWyKTnf06dbJPUbuOtFjkuUVRclTVqqgPUS c2Rg4jwyUgaZQ9XE4aa/yp8FOE+iP5t6FIU6m6pg5tOxEkYwpAyGnbrIbNaww+bK9NEx XMgPPBZUQoGLQPRCK7+XhTmj6ed2tjrQmMDbUH3+FEn7UOe1SOgy+jgIWJZWoTVlGedQ 2blg== X-Gm-Message-State: APjAAAUeeZrRR2xAAudptS2fTzqVx8Ox+TGUm11j6TXAVM7lUqDe1sUl h46wNvduM726EXQUV3iwhG2DZN0XsJGuQjcrZpPLDgRtus0= X-Google-Smtp-Source: APXvYqxxsB5K123XVcsSHMygzJ/E0k3cyWzNjO5Jum/TOS7FjQfqWm6FW4WOsg7pqEUBTUTFf/kVxDmTFUpZsHijC9k= X-Received: by 2002:a1f:e0c2:: with SMTP id x185mr21492305vkg.6.1574783545199; Tue, 26 Nov 2019 07:52:25 -0800 (PST) MIME-Version: 1.0 Date: Tue, 26 Nov 2019 09:52:14 -0600 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000cf529f059841dd03" X-Envelope-From: Subject: Let's allow eval() to be turned off in PHP 8 From: iansltx@gmail.com (Ian Littman) --000000000000cf529f059841dd03 Content-Type: text/plain; charset="UTF-8" Hi all, Let's just say that eval() and create_function() are the cornerstone of PHP-based exploit toolkits. Yes, if the hackers get in there are other problems with your codebase, but as a defense in depth measure most applications need neither create_function() nor the eval() language construct, so they might as well be disabled. create_function() is easy enough to drop with a didabled_functions ini directive, and is going away "no later than PHP 8.0", per its deprecation notice as of 7.2. eval() on the other hand can't be disabled that way, as it's not actually a function. So this seems like an excellent candidate for another ini setting, as from a security standpoint you *want* this change to be global. Yes, if every shared host turned this on by default, old code would break. But I Suhosin allows doing this anyway ( https://stackoverflow.com/questions/25037015/suhosin-and-disable-eval) so it's not like the option hasn't been available...though it's been over four years since we've had a stable release of Suhosin. Similar to disable_functions, if the ini setting turning off eval() got set, you shouldn't be able to override it via ini_set() in code. We can use a similar warning to the display_disabled_function one here. One alternative to adding an entirely new INI setting would be to allow disabled_functions to work on eval. That means that somewhere in the INI parsing/stubbing/warning process (and maybe all three places) will get a bit more complex, but that would have the benefit of not having to explain to anyone editing the ini file that eval() is a language construct rather than a function and thus can't be disabled the normal way (I was just apprised of this mistake last today). From taking a quick look at Suhosin code, the way they're handling this may be somewhat informative for creating a patch directly to core, but as a bolt-on it looks like they can't be as efficient, so any patch to core would be inspired by, rather than a copy of, how that extension's eval-handling is built. I feel strongly enough about this to help with the text side of the RFC, and maybe even dive into php-src to assist with a patch, though I have neither karma for posting the former nor enough C acumen to do the latter all by myself. But I want to make sure I won't get immediately shot down if I try going down that road...and if other folks like the idea, I could use some help here putting it together. What do y'all think about getting this into PHP 8? Thanks in advance, Ian Littman --000000000000cf529f059841dd03--