Edit report at https://bugs.php.net/bug.php?id=62397&edit=1
ID: 62397
Comment by: isee at a dot troll
Reported by: spamik at yum dot pl
Summary: disable_functions = eval does not work
Status: Re-Opened
Type: Feature/Change Request
Package: *General Issues
PHP Version: 5.3.14
Block user comment: N
Private report: N
New Comment:
@anon: pretty sure you just got trolled
Previous Comments:
------------------------------------------------------------------------
[2012-06-28 17:37:40] anon at anon dot anon
@e756937
(1) haven't you heard of include()?
(2) $_GET['path'] not validated
(3) no apparent rhyme or reason to mix of single and double quoting
(4) echo parameter neither quoted nor escaped
(5) echo within eval?
(6) why do you need eval for that at all?
(7) "I also use it for user auth" -- I completely doubt you need to.
(8) exec() is unrelated.
(9) The mere existence of an easy way to disable eval does not mean your host
will do that. Your host can already disable it if they want to. Hosts often let
you specify a custom php.ini or other configuration anyway, and this is
certainly true on a server plan that serves 10k daily uniques for you.
(10) Using a 10minutemail.com address with a commenting system that doesn't
verify the email.
Conclusion => magic_quotes level of IQ
------------------------------------------------------------------------
[2012-06-26 17:59:39] e756937 at rtrtr dot com
I run a website with 10k uniques per day and eval() is CRUCIAL to my business
example:
$page = file_get_contents($_GET['path'].".php");
eval("echo ".$page.";");
I also use it for user auth and access to exec() since my host blocks it
As you can see, eval() is a very good thing to use and I don't want it gone,
kk??
------------------------------------------------------------------------
[2012-06-24 13:58:06] spamik at yum dot pl
good point about assert and preg_replace /e - there also should be option to
disable it then (especialy this /e in preg_replace). Writers of malicious code
so far did not had to use it because eval is enabled in every php version...
As for eval etc. documentation states that it sould be avoided by developers -
and it is actualy. However it used to mask infected, malicious code by those
that hacked php software. eval is commonly used to evaluate base64_encoded
string and that makes very hard to see what code is doing and to detect it
automaticly (by something like antivirus software).
Change on magic_quotes_gpc in php 5.4 is much greater change then turning off
eval by default would be. Since most legitimate software don't use it (since
documentation says its bad)would affect only very few. This also would not
increase security. However it would make code infections so much easier to
detect and analize its nature.
------------------------------------------------------------------------
[2012-06-24 11:25:51] ni...@php.net
Irregardless of the FR, I'd like to point out that eval() is a useful and
legitimate language construct. It *definitely* will not be disabled by default.
I won't argue with the fact that it is commonly misused by ignorant developers,
but this does not mean that eval() itself is in any way fundamentally "evil".
Also, I completely do not understand your arguments that people are migrating
to other languages, because PHP has an eval() construct. All dynamic languages
have an eval() function, including JS, Python and Ruby.
Furthermore you should realize that disabling eval() will not likely improve
the security of your application. There are just to many other ways to execute
code. E.g. the assert() function can be used to evaluate arbitrary code. Or the
preg_replace /e modifier.
But in any case, I don't really see why eval() is a language construct. In my
eyes it could just as well be a function. This would make it disableable and
would also provide other advantages, like allowing its use as a callback
function.
------------------------------------------------------------------------
[2012-06-24 10:05:00] larue...@php.net
okey, change to FR makes sense to me.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62397
--
Edit this bug report at https://bugs.php.net/bug.php?id=62397&edit=1
