php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #62397 disable_functions = eval does not work
Submitted: 2012-06-23 00:24 UTC Modified: 2024-02-09 09:44 UTC
Votes:41
Avg. Score:4.8 ± 0.5
Reproduced:36 of 36 (100.0%)
Same Version:11 (30.6%)
Same OS:13 (36.1%)
From: spamik at yum dot pl Assigned:
Status: Re-Opened Package: *General Issues
PHP Version: 5.3.14 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
30 + 19 = ?
Subscribe to this entry?

 
 [2012-06-23 00:24 UTC] spamik at yum dot pl
Description:
------------
disable_functions = eval does not work.

eval is often used to obfucate code by malicious viruses. I see no reason why 
blocking access to eval() is not doable.


Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-23 07:28 UTC] reeze dot xia at gmail dot com
eval is not a function but language construct
http://php.net/eval so it cannot be disabled by adding it to disable_functions
 [2012-06-23 09:14 UTC] laruence@php.net
-Status: Open +Status: Not a bug
 [2012-06-23 09:14 UTC] laruence@php.net
eval is not a function, if you want to disable it, you may refer to Suhosin 
thanks
 [2012-06-23 10:56 UTC] anon at anon dot anon
A reason why a bug exists is not a reason why it is not a bug.
 [2012-06-23 12:29 UTC] laruence@php.net
as I said,  eval is not a *function*,  so disable_*functions* has no effect to 
eval..
 [2012-06-23 12:52 UTC] bobwei9 at hotmail dot com
Why can't you simply add a new core directive for disabling this language construct?
 [2012-06-24 03:56 UTC] krzf83 at gmail dot com
"eval is not a function but language construct" - that might be the reason why 
disable_functions don't work on it now but that does not mean it could not or 
should not.

I would not dismiss this isssue so easily. Eval problem caused that php is 
currently (almost) only one language is so often infected. It allows for 
attacker to hide code, purpose, use ecodings (like base64) to diminish any hope 
of detection by searching for common traits (like antivirus software does).

Eval is a functionality of php and could be disabled if apropriate modifications 
to php source code were made.
 [2012-06-24 03:59 UTC] krzf83 at gmail dot com
treat it as feature request if it helps you sleep at night. However this issue is 
critical in face of current mailicous code boom. Eval (by base64_encode etc) does 
not allow for any scanning and detection. This funcionality of php had begun its 
downfall really. People are migrating to other languages just because infections 
there are rare and code cannot be just like that obfucated!
 [2012-06-24 04:02 UTC] spamik at yum dot pl
feature request then
 [2012-06-24 04:08 UTC] spamik at yum dot pl
-Type: Bug +Type: Feature/Change Request
 [2012-06-24 04:08 UTC] spamik at yum dot pl
I think that that not only should be done but also made default php behavior, to 
stop widespread madness of php code infection. Eval should be by default disabled 
in php like 5.5 ...
 [2012-06-24 10:05 UTC] laruence@php.net
okey, change to FR makes sense to me.
 [2012-06-24 10:05 UTC] laruence@php.net
-Status: Not a bug +Status: Re-Opened
 [2012-06-24 11:25 UTC] nikic@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 13:58 UTC] 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-26 17:59 UTC] 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-28 17:37 UTC] 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-29 16:31 UTC] isee at a dot troll
@anon: pretty sure you just got trolled
 [2015-03-24 12:12 UTC] phpbugs at notmyaddie dot com
Considering how prolific the use of eval() is in malicious code I cannot believe it can't be turned off without installing something like suhosin. Arguing what it is is beside the point. It is a gaping hole in the security and stability of php servers that cannot be closed without 3'rd party software.

"If eval() is the answer, you're almost certainly asking the
wrong question. -- Rasmus Lerdorf, BDFL of PHP"

And if you're going to argue that a function is not evil and should not be used for evil things, tell that to all the 'hackers' using it. I want to install a gate at my door by turning this off. Telling me I can't because I should not break into my own house is pointless
 [2019-04-28 15:57 UTC] beberlei@php.net
The following pull request has been associated:

Patch Name: Fix bug #62397 - disable_functions does not work with eval.
On GitHub:  https://github.com/php/php-src/pull/4084
Patch:      https://github.com/php/php-src/pull/4084.patch
 [2019-05-14 22:00 UTC] petk@php.net
Automatic comment on behalf of kontakt@beberlei.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=050d299364ded5cb7b878bc515aa763c9c623c4b
Log: Fix bug #62397 - disable_functions does not work with eval.
 [2019-05-14 22:00 UTC] petk@php.net
-Status: Re-Opened +Status: Closed
 [2019-06-03 09:20 UTC] krakjoe@php.net
Automatic comment on behalf of krakjoe
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ff96f25b12287de8105305b6f92c7714833066a7
Log: Revert "Fix bug #62397 - disable_functions does not work with eval."
 [2019-06-03 09:24 UTC] petk@php.net
-Status: Closed +Status: Re-Opened
 [2019-06-03 09:24 UTC] petk@php.net
Re-opened bug and we're back at the beginning via above revert so when that will be more properly fixed we can move forward here I guess.
 [2019-06-03 09:30 UTC] krakjoe@php.net
-Status: Re-Opened +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2019-06-03 09:30 UTC] krakjoe@php.net
There is no implementation of this that can provide any security. 

There is no difference between eval and include, if a malicious hacker finds themselves on a system where eval is disabled, they can just dump what they would eval and include it.

By the time a hacker has permission to execute unsafe code via eval or by any other means, it is too late.
 [2021-09-09 01:22 UTC] jake at qzdesign dot co dot uk
@krakjoe

> There is no difference between eval and include

This is not true.  If malicious code were required to write a file to be `!include`d, this could be monitored and potentially blocked by a separate tool running at the filesystem level.

> By the time a hacker has permission to execute unsafe code via eval or by any other means, it is too late.

Isn't that a bit like saying 2FA is pointless because by the time your password has been cracked it's too late?
 [2024-02-09 09:44 UTC] bukka@php.net
-Status: Closed +Status: Re-Opened -Assigned To: krakjoe +Assigned To:
 [2024-02-09 09:44 UTC] bukka@php.net
Re-opening as single developer cannot make this decision. This needs to come from RFC and I believe there are some good arguments for disabling eval.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 23 15:01:29 2024 UTC