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: 2012-06-24 10:05 UTC
Votes:12
Avg. Score:4.5 ± 0.8
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:3 (30.0%)
From: spamik at yum dot pl Assigned:
Status: Re-Opened Package: *General Issues
PHP Version: 5.3.14 OS:
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [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

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
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 16 22:02:05 2014 UTC