On Apr 3, 14:01, Cris Bailiff wrote:
>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:
[example snipped]

Cris,

You're right, of course. My example turned out to be too simple compared
to the actual CGI_Lite code. It's been a while since I looked at it.
I dug it out and found it, and tested it (it fails). This snippet
from CGI_Lite is the problem:

--
	if ($current_buffer =~ 
            /(.*?)(?:\015?\012)?-*$boundary-*[\015\012]*(?=(.*))/os) {
--
[...]
>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).
It doesn't die or anything, but the regex fails to find the boundary
string.
>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...
I agree with you that the bug is not in libcurl of course.. as far as
CGI_Lite is concerned, my systems are no problem :-)  But CGI_Lite is
used out there, and curl (before that CGI_Lite compatibility patch was
added) couldn't post forms to those sites reliably.  It would work sometimes
and fail at other times, depending on the output of the rand() function..
truly pseudo-random behaviour :-)
Tor