"be consistent" | |
PerlMonks |
Re^3: Define regex substitution $1,$2,... from a stringby afoken (Chancellor) |
on May 25, 2016 at 21:06 UTC ( [id://1164142]=note: print w/replies, xml ) | Need Help?? |
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. ;-) Yes, string eval is problematic with arbiatary input. But: How much harm can be done? If the script runs with user privileges (not root privileges) from a login shell, the worst thing that can happen is that the user executes some perl code with his/her own privileges. Nothing worse can happen than when you allow the user to execute perl -e SOMETHING. "Here's some rope, try not to hang yourself." If the script runs with user privileges, but from a network context (started from a webserver, from a mail handler, from an IRC bot, from a restricted shell invoked by some networked program), s///ee might be a bad idea. It allows an attacker to execute arbitary perl code, and from there, arbitary code on the machine, with user privileges. If the script runs with root privileges, perhaps using a setuid wrapper, s///ee is a plain stupid idea. Any user could run arbitary perl code, and from there, arbitary code on the machine, with root privileges. Root privileges + network + s///ee is the digital equivalent of the Darwin award. Now what? You could try a two-step aproach. First extract all interesting parts of the input, collect that in an array. Then use a template string and replace markers in the template with array elements.
Output:
<Update>Note that @array is empty if nothing was matched (to be more precise: nothing was captured). You may want to abort with an error if @array is empty.</Update> So, we can do that with just one /e. Is it secure now? NO, sorry. Regular expression patterns may contain arbitary perl code:
My relatively new perls (5.14.1, 5.18.1) refuses to execute the code, even the old 5.8.8 from a fresh Slackware 12.1 (dated 2008) installation in a virtual machine:
The really ancient 5.005_03 from Slackware 4.0 (released in 1999) has a different error message:
BUT: Once you use re 'eval';, or someone manages to trick perl into importing eval from re, this little bit of protection is gone and all perls back to at least 5.005_03 start executing arbitary code from the rexexp:
Access to perl without s///ee, and thus the ability to execute arbitary code. Ouch. <Update>You may want to use Safe for executing the critical code. But then, Safe is trying to prevent "evil" things instead of only allowing "secure" things. One bug in Safe and you loose again. And even Safe can't prevent everything, see RISKS in Safe.</Update> Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
In Section
Seekers of Perl Wisdom
|
|