Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107861 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54827 invoked from network); 26 Nov 2019 18:07:02 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 26 Nov 2019 18:07:02 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 903C12D1FC3 for ; Tue, 26 Nov 2019 08:01:43 -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-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 08:01:43 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id m9so13104925vsq.7 for ; Tue, 26 Nov 2019 08:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kRw9qpSgyfMSt6IPnBg6i+y7e6y+H8BEQjGWM/0/3qw=; b=G42A9Yk14/VT2YOhBtNWYJOigIx9kmaZKguvkCGILfSyld1T4Jov43TwsXKeh5KfV7 fEer/7uA8fBUTQwHchfQPX3oHemg+bBKpatU9k/wfTOPc7e683U+LarFh+b3q7DBXe0V 41ZAtMi86i+yBjs6YuynerTtxcq11x4HC70QWp9rlmwUw/ASu221HKK5qfKZnVkN04cK Y7eEkTJJkVV4HsII4k62HY5DhnRrHQwnRL9u/kmxoIqhoP39e1cLasUqTpoiyVIMOZi9 ZyOOPcCqhCCYDLLXQO1iXGgrZFG/yhfmJJmtc88XrnteYpcfFAc/ozCXy5FLRUcnFzsF meNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kRw9qpSgyfMSt6IPnBg6i+y7e6y+H8BEQjGWM/0/3qw=; b=RIvqku+eyPbFBVlqWIxTdSvo9MuT8ZGgmBrlxmPCrYSMvTKPo9a9AdUjlTKbGwheFy wBArvfq3CI63tbxG9LVOYc+oDKNhSrGgqUIOPp/AEJPYnJgWu9rhxiyUlMF7Kyh9MavL NH8tqR4apoTbwT4GVfvc8HVyF2I5Ap1kz6FQA1CC8MgZSYlBIJYoPw2ca2uBKbHaEnjs 3ohB71otedcLgVjCUjN5NKsSe4NaldNE+uvpgb3vlEA9z0dNE05kmfrGSMKkN429XRXn bUYU2VXNE1aOEEA97ohMNsCHk+UcngtvIKQ159ruhHVJyVfYw+mzR/ywNejoUyq83Zpo ot3A== X-Gm-Message-State: APjAAAXaX7o2EMQtUB0kM1nN2kX9WfMGE7OiB3uVAm3jC5leAnyxLLQw 0h4qdxfrvhgbxbsJdvxfH5WLFVP1vOw6DVdyVLkl4Q== X-Google-Smtp-Source: APXvYqzspKUWydRSkYQEDU0dlH6t6Ts0XE0cKovsPjsDxYnwNJ0eTk2x88gkU9FTZzNXHbBthuQg1I0yOdzcnzlIEOQ= X-Received: by 2002:a67:dc0b:: with SMTP id x11mr22499537vsj.167.1574784102486; Tue, 26 Nov 2019 08:01:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 26 Nov 2019 11:01:31 -0500 Message-ID: To: Ian Littman Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000006d8ee059841ff21" X-Envelope-From: Subject: Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8 From: dohpaz@gmail.com (Ken Stanley) --00000000000006d8ee059841ff21 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 26, 2019 at 10:53 AM Ian Littman wrote: > What do y'all think about getting this into PHP 8? > So long as the default behavior is to leave it available, I'm okay with this. Any app that relies on twig/twig, phpunit/phpunit, many symfony packages, dompdf/dompdf, etc relies on being able to use eval(). On Tue, Nov 26, 2019 at 10:53 AM Ian Littman wrote: > 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 > --00000000000006d8ee059841ff21--