Tor Arntsen wrote:

> It is (in a sense), because Perl regex'es are usually between '/'
boundaries
> (e.g. "if (/(\d+)$other_pattern/) $value=$1;", which BTW also show the
> type of code that exists in that CGI_Lite Perl package.
$other_pattern would
> be that form separator string.)

Tor,

either there is some misunderstanding in your sample perl code, or the
CGI_lite module has some serious coding bugs (which probably lead to
security issues) - interpolating into a regex using a variable, as in
your example, shouldn't lead to confusion on perls behalf - the
characters in the variable can hold regex characters just fine - perl
knows to take them literally.

Consider this example - takes a pattern on the first line, then matches
against following lines of input:

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

my $other_pattern=<>; # read pattern
chomp $other_pattern;

while(<>) { # read a line
         chomp;
         my $value=0;
         if (/(\d+)$other_pattern/) { $value=$1 };
         print "value=$value \n";
}

Feed in:

abc
123abc
456abc

and you get

value=123
value=456

as output, as expected.

Now run again, and feed in an initial pattern containing special
characters, then some data:

/foo/bar/;
123/foo/bar/;
456/foo/bar/;

you should get

value=123
value=456

just fine. (I do). If CGI_lite is complaining (or 'die'ing with errors)
at this point, it most likely has done something highly dangerous -
taken the user input, joined it with the // characters of a regex, and
then tried to evaluate the whole string as literal perl (using,
unsurprisingly, the function 'eval()').

If the code did this without removing the special characters, then the
eval could fail due to a syntax error (if you're lucky), or do something
really nasty (if you're unlucky).

I'd take a closer look at the issue before settling for just fixing up
libcurl, if you care about the security of any of your systems...

Cris
Received on 2002-04-03