8 ms·
Eval in replace funtion.. But why?!
by lcedp 13y ago
Eval in replace funtion.. But why?!
- Afforess 13y agoBecause PHP.
- devgutt 13y agohttp://docs.python.org/2/library/functions.html#eval http://docs.python.org/2/library/functions.html#eval
- echohack 13y agohttps://github.com/thijsdezoete/noevil https://github.com/thijsdezoete/noevil
- deadreturns2 13y agoHe's talking about the preg_replace /e modifier not eval, the function.
- valleyer 13y agonote: “... in replace function”
- pjscott 13y agoYes, Python has eval, but it doesn't hide in the bushes and ambush you. The same can not be said for preg_replace and the /e option.
- Dylan16807 13y agoJust curious, how many points does your comment have right now even though it's completely wrong? I'm not insulting you for making a tiny mistake, I'm wondering why a 7 hour old post with multiple 6 hour old corrections attached to it still has a positive score.
- devgutt 13y agobecause eval is the real source of the problem
- Dylan16807 13y agoWould you remove the ability to load libraries, too? Because that's as dangerous as eval when it comes to purposely writing code to run external commands. The ability of a programming language to run code is not the cause of the problem, it's having domain-breaking misleading functions like a string replacer that can compile and execute.
- devgutt 13y agoyeah because libraries, which is available for scrutiny of a community (and you), is the same as a function that can run any arbitrary code in your program at runtime.
- Dylan16807 13y agoIf you can load libraries at runtime, you can load a secret malicious library, or replace a standard library with arbitrary code before triggering the loading. So would you remove that ability to avoid its exploitation potential by malware?
- deleted 13y ago[deleted]
- jasonlotito 13y agoYou mean Perl, right? Because that's what PCRE is, Perl Compatible Regular Expressions, and the e modifier does in fact come from Perl.
- nly 13y agoIn Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. The documentation also suggests enabling taint checking or "constrained evaluation within a Safe compartment". Contrast this to PHP, where /e appears to be on by default and there's no mention of it whatsoever in the documentation, except in the change log to say it's deprecated in 5.5. Also PCRE, which PHP uses, is a C library... so I doubt it has any eval functionality. PHP implements this on top of PCRE to mimic Perl. No I'm afraid it's another shoddy PHP design decision to blame here.
- ars 13y agoCute rant. But PHP uses /e in exactly the same way: The /e is part of the literal regexp. > Contrast this to PHP, where /e appears to be on by default No, /e is not enabled by default. > and there's no mention of it whatsoever in the documentation Yah, that's because it's not on by default. Do you expect them to document every idea you make up? > is a C library... so I doubt it has any eval functionality pcre_callout() > No I'm afraid it's another shoddy PHP design decision to blame here. No I'm afraid it's just another ignorant PHP basher to blame here. Do you just like to make stuff up about PHP, then bash it? PS. To anyone reading this: Don't use /e with untrusted input, it's not safe. But if must assign blame, then blame perl for it, not php.
- pyre 13y ago| Don't use /e with untrusted input This isn't a case of someone running: preg_replace($VAR1 + "/e", $VAR2,''); No one passed untrusted input to '/e.' It's a case of untrusted input being passed to preg_replace() in an insecure way, which allowed '/e' to be enabled. All of this is sort of irrelevant anyways. The developers did not add the preg_replace() function, the attacker did so as a way to eval code without directly calling eval() (which would be easy to spot in the code, since it should so rarely be called in practice).