Re: execution inside of Perl reg ex?

[rpc <h () ckz org>]

Hi,

On Thu, 4 Jan 2001 18:08:46 +0100, Pascal Bouchareine said:

> well, i'm certainly wrong on some points but i came to the following
>  point of view (which i'd love you to clarify if i misunderstood some facts)
>
>  IMHO, perl first evals any special chars (backquotes and the like),
>  interprets your line, and once it knows exactly what to do with
>  your input line, expands scalars and variables. Thus, meta-characters
>  and backquotes are not interpreted, since the interpreter looked for them
>  before the $variable expansion. If your line is a function call, and this

Just a minor point on variable interpolation. A literal '$' for example can be
interpolated using a substitution. Perl can do interpolation as many times as
you tell it to.

#!/usr/bin/perl -w
use strict;

my $foo = "bleh";
my $bar = "foo is \$foo";       # literal '$foo', not the lexical.

print "$bar\n";                         # foo is $foo
$bar =~ s/(\$\w+)/$1/gee;       # double interpolate
print "$bar\n";                         # foo is bleh

This causes perl to run the interpolation again _after_ the substitution.

<snip>
>  Another way to see this point is evaluated code. If you happen to feed a
>  script interpreter with user input (such as ``/system() or eval(), which is a
>  perl interpreter inside the perl interpreter), then it gets dangerous.


If you pass user supplied data to eval, you are fucked. Plain and simple. :)


>  Another last point may be twice-evaluated things. For example, with
>  double calls to uncgi(), where %250d is "magically" translated
>  to %0d.

uncgi is not a Perl function, however there might be some functions that this
is applicable to.

>  So:
>
>  $n =~ /$user_input/
>
>  isn't sound dangerous yet (we didn't find any // bug, for now :), but
>  may be one day..

I highly doubt there are any // related bugs with the regex engine. The regex
opcodes are generated long before interpolation, so there is no chance of
confusing Perl into believing a part of the user input should be interpreted as
the end of a regex, etc.

<snip>
>  \Q \E is safe (for the moment) and is supplied as a "don't trust it" keyword
>  for perl. Sounds really better than nothing.
>
>  On Wed, Jan 03, 2001 at 10:34:18AM +0000, sporty o'one wrote:
>  > this is exactly the reason for \Q\E
>  >
>  > so \Q$this\E is safe


\Q \E is not a security feature. Taint is. If you want (?:more)? secure user
input
__use taint mode!__, and optionally use the Safe module.

thanks,
--rpc


>  >
>  > >  As an operator, Perl will shell any command you put inside back
>  > > quotes and return the result of the shelled command. I assume this
>  > > would work inside a regular expression, but I haven't tried.
>  > >
>
>  --
>  Kalou.
>           .ascii "T[fhBOfXf5B@f1ChjAX4APPZHf1Chfh/xh/tmpT[RSTYjOX4D2p"