plperl security

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

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