Thread: plperl security
There is a known security issue with the perl Safe module versions up to and including 2.07 (and 2.08 had a life of 1 day before 2.09 was released). see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1323 Currently we have this in plperl.c: "require Safe;" I am thinking of submitting a patch to replace this with "use Safe 2.09;" to enforce use of a version without the known vulnerability. Any objections? cheers andrew
> Currently we have this in plperl.c: > "require Safe;" > > I am thinking of submitting a patch to replace this with "use Safe > 2.09;" to enforce use of a version without the known vulnerability. > > Any objections? I have none, except will 2.09 work with 5.00503? > > cheers > > andrew > > > _______________________________________________ > Plperlng-devel mailing list > Plperlng-devel@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/plperlng-devel -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Joshua D. Drake wrote: > >> Currently we have this in plperl.c: >> "require Safe;" >> >> I am thinking of submitting a patch to replace this with "use Safe >> 2.09;" to enforce use of a version without the known vulnerability. >> >> Any objections? > > > I have none, except will 2.09 work with 5.00503? I will see about getting a test done, unless someone on one of those systems with an older perl can try upgrading the Safe module from CPAN for us. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Currently we have this in plperl.c:
> "require Safe;"
> I am thinking of submitting a patch to replace this with "use Safe
> 2.09;" to enforce use of a version without the known vulnerability.
This would break both plperl and plperlu on older Perls. Please see
if you can avoid breaking plperlu.
For that matter, does plperl.c really cope properly with a failure in
this code at all? I sure don't see anything that looks like error
handling in plperl_init_interp().
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Currently we have this in plperl.c: >> "require Safe;" >>I am thinking of submitting a patch to replace this with "use Safe >>2.09;" to enforce use of a version without the known vulnerability. >> >> > >This would break both plperl and plperlu on older Perls. Please see >if you can avoid breaking plperlu. > >For that matter, does plperl.c really cope properly with a failure in >this code at all? I sure don't see anything that looks like error >handling in plperl_init_interp(). > > > > I will look at it. It will probably require some non-trivial rework. I do agree that we should not break more old stuff than is necessary. cheers andrew
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>
>>
>>> Currently we have this in plperl.c:
>>> "require Safe;"
>>> I am thinking of submitting a patch to replace this with "use Safe
>>> 2.09;" to enforce use of a version without the known vulnerability.
>>>
>>
>>
>> This would break both plperl and plperlu on older Perls. Please see
>> if you can avoid breaking plperlu.
>>
>> For that matter, does plperl.c really cope properly with a failure in
>> this code at all? I sure don't see anything that looks like error
>> handling in plperl_init_interp().
>>
>>
>>
>>
>
> I will look at it. It will probably require some non-trivial rework.
>
> I do agree that we should not break more old stuff than is necessary.
>
>
The thing is that unlike TCL we have one interpreter for both trusted
and untrusted cases.
My thinking is to factor out all the code that only applies to trusted
cases from the interpreter init code, and only call it if we try to
compile a trusted function and it hasn't been run yet. Does that seem
reasonable?
The code in question would be:
always in interp init:
SPI::bootstrap(); use vars qw(%_SHARED); sub ::mkunsafefunc {return eval(qq[ sub { $_[0] $_[1] } ]); }
only if needed for trusted cases:
use Safe 2.09; use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
$PLContainer->permit_only(':default');$PLContainer->permit(':base_math'); $PLContainer->share(qw[&elog
&spi_exec_query&DEBUG &LOG &INFO
&NOTICE &WARNING &ERROR %SHARED ]); sub ::mksafefunc { return $PLContainer->reval(qq[sub { $_[0]
$_[1]}]); }
Still looking at robustness issues.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> The thing is that unlike TCL we have one interpreter for both trusted
> and untrusted cases.
> My thinking is to factor out all the code that only applies to trusted
> cases from the interpreter init code, and only call it if we try to
> compile a trusted function and it hasn't been run yet. Does that seem
> reasonable?
That would work. You'd need two state flags instead of just one, but
that doesn't seem bad.
Recovering when you get an error is probably the trickiest part of this.
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>The thing is that unlike TCL we have one interpreter for both trusted >>and untrusted cases. >> >> > > > >>My thinking is to factor out all the code that only applies to trusted >>cases from the interpreter init code, and only call it if we try to >>compile a trusted function and it hasn't been run yet. Does that seem >>reasonable? >> >> > >That would work. You'd need two state flags instead of just one, but >that doesn't seem bad. > > 2? 'splain please :-) cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> That would work. You'd need two state flags instead of just one, but
>> that doesn't seem bad.
> 'splain please :-)
Maybe you weren't thinking of the same thing, but what I was imagining
was one state flag to remember that you'd created the interpreter (and
loaded the unsafe-func support into it), then a second one to remember
whether you've loaded the safe-func support. There are various ways to
represent this of course, but the point is there need to be three
persistent states.
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Tom Lane wrote: >> >> >>>That would work. You'd need two state flags instead of just one, but >>>that doesn't seem bad. >>> >>> > > > >>'splain please :-) >> >> > >Maybe you weren't thinking of the same thing, but what I was imagining >was one state flag to remember that you'd created the interpreter (and >loaded the unsafe-func support into it), then a second one to remember >whether you've loaded the safe-func support. There are various ways to >represent this of course, but the point is there need to be three >persistent states. > > > > Ahh, ok. We already have a state var to remember the first part (plperl_firstcall). Just need one new one I think. cheers andrew
Tom Lane wrote: > >Recovering when you get an error is probably the trickiest part of this. > > OK, I have a setup that instead of refusing to load trusted functions if the Safe version is not up to date, forces them to error out by calling elog(ERROR...), thus: andrew=# select tval(); ERROR: trusted perl functions disabled - please upgrade perl Safe module to at least 2.09 This seems like perfectly reasonable recovery to me. Thoughts? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> OK, I have a setup that instead of refusing to load trusted functions if
> the Safe version is not up to date, forces them to error out by calling
> elog(ERROR...), thus:
> andrew=# select tval();
> ERROR: trusted perl functions disabled - please upgrade perl Safe
> module to at least 2.09
> This seems like perfectly reasonable recovery to me. Thoughts?
Works for me --- and it doesn't leak memory across repeated failures,
right?
Patch please?
regards, tom lane
Hello, I know there is a patch coming Monday with a great deal of bug fixes. J On Fri, 9 Jul 2004, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > OK, I have a setup that instead of refusing to load trusted functions if > > the Safe version is not up to date, forces them to error out by calling > > elog(ERROR...), thus: > > > andrew=# select tval(); > > ERROR: trusted perl functions disabled - please upgrade perl Safe > > module to at least 2.09 > > > This seems like perfectly reasonable recovery to me. Thoughts? > > Works for me --- and it doesn't leak memory across repeated failures, > right? > > Patch please? > > regards, tom lane > _______________________________________________ > Plperlng-devel mailing list > Plperlng-devel@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/plperlng-devel > -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead