Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107871
MIME-Version: 1.0
References: <CAAupm8h5Aa4EmnGnHX1iVgcQTCpmW-3yD4e6m7aouZFiSCtGrA@mail.gmail.com>
 <05388310-2c80-2b42-a564-0fda2b6a2396@gmail.com>
In-Reply-To: <05388310-2c80-2b42-a564-0fda2b6a2396@gmail.com>
Date: Tue, 26 Nov 2019 16:44:24 -0600
Message-ID: <CAAupm8gDxAjiW0Ox7jWAC0fEKUwSwYPA27NjHUawTVFd8RDc1w@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d80f950598479fbb"
Subject: Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8
From: iansltx@gmail.com (Ian Littman)

--000000000000d80f950598479fbb
Content-Type: text/plain; charset="UTF-8"

Main holes that this closes are:

1. Being able to run code fetched remotely without ever hitting disk
2. Being able to run code transformed directly from an obfuscated state

I have examples of both techniques; reply directly to me if you're curious.
One of the examples breaks if create_function isn't available. The other
two break if eval() isn't available.

One interesting thing with item #1 is that it allows for remote arbitrary
code execution even if no include-able path on a server is writable. This
comes into play if there's a supply chain attack on your app. Say, an
infected update on a CMS plugin. Get an eval() of a file_get_contents() of
a URL into the code and...well, you get code execution that (if you're
lucky) only leaves a trace in logs. If you have to write a file somewhere
first, then include it, you've got a bit more of a footprint.

Can you work around these restrictions? Yep, but it takes a bit more effort
than the current setup. It doesn't make a server secure by any stretch, but
it reduces its attack surface slightly, and reduces the universe of
malicious code that won't error out, forcing malefactors to work just a bit
harder.

To be crystal clear, **I am not asking for disabling eval() by default**.
Just for it to be disable-able, as create_function already is. This isn't a
resolution for all things security-related. Just one more thing to slow
attackers down.

Heck, if we can't agree on having the ability to disable eval() (which,
again, Suhosin has), how about catching cases where someone throws eval
into disabled_functions and warning them that the difference between a
function and a language construct renders their INI declaration useless?

Ian

On Tue, Nov 26, 2019 at 4:21 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > 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.
>
> I get defense in depth, but I don't understand what it means in this
> case. Since you're talking about disabling functions, I assume we're
> talking about the situation where there's code execution access. From
> that point, you can execute any code. What is the value of disabling
> eval() here? You don't need eval, you can run any code you want
> directly! Am I missing something here?
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>

--000000000000d80f950598479fbb--