Thread: plperl security

plperl security

From
Andrew Dunstan
Date:
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




Re: [Plperlng-devel] plperl security

From
"Joshua D. Drake"
Date:
> 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

Re: [Plperlng-devel] plperl security

From
Andrew Dunstan
Date:

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


Re: plperl security

From
Tom Lane
Date:
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


Re: plperl security

From
Andrew Dunstan
Date:

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


Re: plperl security

From
Andrew Dunstan
Date:

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


Re: plperl security

From
Tom Lane
Date:
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


Re: plperl security

From
Andrew Dunstan
Date:

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




Re: plperl security

From
Tom Lane
Date:
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


Re: plperl security

From
Andrew Dunstan
Date:

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


Re: plperl security

From
Andrew Dunstan
Date:

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





Re: plperl security

From
Tom Lane
Date:
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


Re: [Plperlng-devel] Re: plperl security

From
"Joshua D. Drake"
Date:
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