From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Murawski <markm-lists@intellasoft.net>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Bug plperl.c
Date: Fri, 25 Feb 2022 16:36:42 -0500
Message-ID: <2081576.1645825002@sss.pgh.pa.us> (raw)
In-Reply-To: <73ce9f5a-c11d-2626-199b-8b9dde1d432e@intellasoft.net>
References: <9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net>
<821293.1645559302@sss.pgh.pa.us>
<d57829b8-e0b3-ee63-8966-f2267e7ffa41@intellasoft.net>
<bcfaa4e4-6699-8c8b-0201-37889ff3b1e8@intellasoft.net>
<73ce9f5a-c11d-2626-199b-8b9dde1d432e@intellasoft.net>
Mark Murawski <markm-lists@intellasoft.net> writes:
> Were you able to reproduce using the updated example?
Sorry, this wasn't at the top of my to-do queue. It does reproduce
for me, and I think what we need to do about it is the attached.
In the normal code paths, this change will disallow usage of SPI until
we have completed compile_plperl_function and have a valid "prodesc"
to look at. I didn't care for your proposed workaround because
(1) it'd allow execution of non-read-only code during compilation
of a supposedly read-only function;
(2) it didn't patch the dozen or so other places where plperl SPI
functions could try to dereference prodesc;
(3) allowing code execution during function validation is, if not
an actual security hole, certainly on the hairy edge of being one.
I'm somewhat comforted about (3) because it seems the problem is only
reachable from plperlu not plperl. It's still pretty scary though.
I realize that this solution might make your use-case rather awkward.
As far as function validation goes, you can still create your functions
by setting check_function_bodies = off. If you feel you need to have
Perl code that executes during compilation otherwise, I'm not sure
what to tell you, except that it doesn't seem like a great idea.
I also noticed while looking at this that the relatively-recently-added
plperl_spi_commit and plperl_spi_rollback functions neglected to do
check_spi_usage_allowed(), so this fixes that too.
regards, tom lane
Attachments:prevent-spi-execution-during-plperl-compilation.patch (text/x-diff, 1.3K) downloaddiff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.cindex 81d9c46e00..3f221ee01b 100644--- a/src/pl/plperl/plperl.c+++ b/src/pl/plperl/plperl.c@@ -3097,6 +3097,21 @@ check_spi_usage_allowed(void)
/* simple croak as we don't want to involve PostgreSQL code */
croak("SPI functions can not be used in END blocks");
}
++ /*+ * Disallow SPI usage if we're not executing a fully-compiled plperl+ * function. It might seem impossible to get here in that case, but there+ * are cases where Perl will try to execute code during compilation. If+ * we proceed we are likely to crash trying to dereference the prodesc+ * pointer. Working around that might be possible, but it seems unwise+ * because it'd allow code execution to happen while validating a+ * function, which is undesirable.+ */+ if (current_call_data == NULL || current_call_data->prodesc == NULL)+ {+ /* simple croak as we don't want to involve PostgreSQL code */+ croak("SPI functions can not be used during function compilation");+ }
}
@@ -3961,6 +3976,8 @@ plperl_spi_commit(void)
{
MemoryContext oldcontext = CurrentMemoryContext;
+ check_spi_usage_allowed();+
PG_TRY();
{
SPI_commit();
@@ -3986,6 +4003,8 @@ plperl_spi_rollback(void)
{
MemoryContext oldcontext = CurrentMemoryContext;
+ check_spi_usage_allowed();+
PG_TRY();
{
SPI_rollback();
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, markm-lists@intellasoft.net, pgsql-bugs@lists.postgresql.org
Subject: Re: Bug plperl.c
In-Reply-To: <2081576.1645825002@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox