8000 Use a separate interpreter for each calling SQL userid in plperl and … · rshsdev/postgres@3b4c327 · GitHub
[go: up one dir, main page]
Skip to content

Commit 3b4c327

Browse files
tglsfdctglsfdc
committed
Use a separate interpreter for each calling SQL userid in plperl and pltcl.
There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
1 parent 65a192c commit 3b4c327

10 files changed

+814
-384
lines changed

‎doc/src/sgml/installation.sgml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -163,6 +163,11 @@ su - postgres
163163
recent <productname>Perl</productname> versions, but it was not
164164
in earlier versions, and in any case it is the choice of whomever
165165
installed Perl at your site.
166+
If you intend to make more than incidental use of
167+
<application>PL/Perl</application>, you should ensure that the
168+
<productname>Perl</productname> installation was built with the
169+
<literal>usemultiplicity</> option enabled (<literal>perl -V</>
170+
will show whether this is the case).
166171
</para>
167172

168173
<para>

‎doc/src/sgml/plperl.sgml

Lines changed: 44 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@
3939
<para>
4040
Users of source packages must specially enable the build of
4141
PL/Perl during the installation process. (Refer to <xref
42-
linkend="install-short"> for more information.) Users of
42+
linkend="installation"> for more information.) Users of
4343
binary packages might find PL/Perl in a separate subpackage.
4444
</para>
4545
</note>
@@ -81,7 +81,7 @@ $$ LANGUAGE plperl;
8181
most convenient to use dollar quoting (see <xref
8282
linkend="sql-syntax-dollar-quoting">) for the string constant.
8383
If you choose to use escape string syntax <literal>E''</>,
84-
you must double the single quote marks (<literal>'</>) and backslashes
84+
you must double any single quote marks (<literal>'</>) and backslashes
8585
(<literal>\</>) used in the body of the function
8686
(see <xref linkend="sql-syntax-strings">).
8787
</para>
@@ -606,6 +606,23 @@ $$ LANGUAGE plperl;
606606
<literal>return $_SHARED{myquote}-&gt;($_[0]);</literal>
607607
at the expense of readability.)
608608
</para>
609+
610+
<para>
611+
For security reasons, PL/Perl executes functions called by any one SQL role
612+
in a separate Perl interpreter for that role. This prevents accidental or
613+
malicious interference by one user with the behavior of another user's
614+
PL/Perl functions. Each such interpreter has its own value of the
615+
<varname>%_SHARED</varname> variable and other global state. Thus, two
616+
PL/Perl functions will share the same value of <varname>%_SHARED</varname>
617+
if and only if they are executed by the same SQL role. In an application
618+
wherein a single session executes code under multiple SQL roles (via
619+
<literal>SECURITY DEFINER</> functions, use of <command>SET ROLE</>, etc)
620+
you may need to take explicit steps to ensure that PL/Perl functions can
621+
share data via <varname>%_SHARED</varname>. To do that, make sure that
622+
functions that should communicate are owned by the same user, and mark
623+
them <literal>SECURITY DEFINER</>. You must of course take care that
624+
such functions can't be used to do anything unintended.
625+
</para>
609626
</sect1>
610627

611628
<sect1 id="plperl-trusted">
@@ -673,21 +690,31 @@ $$ LANGUAGE plperl;
673690
</para>
674691

675692
<note>
676-
<para>
677-
For security reasons, to stop a leak of privileged operations from
678-
<application>PL/PerlU</> to <application>PL/Perl</>, these two languages
679-
have to run in separate instances of the Perl interpreter. If your
680-
Perl installation has been appropriately compiled, this is not a problem.
681-
However, not all installations are compiled with the requisite flags.
682-
If <productname>PostgreSQL</> detects that this is the case then it will
683-
not start a second interpreter, but instead create an error. In
684-
consequence, in such an installation, you cannot use both
685-
<application>PL/PerlU</> and <application>PL/Perl</> in the same backend
686-
process. The remedy for this is to obtain a Perl installation created
687-
with the appropriate flags, namely either <literal>usemultiplicity</> or
688-
both <literal>usethreads</> and <literal>useithreads</>.
689-
For more details,see the <literal>perlembed</> manual page.
690-
</para>
693+
<para>
694+
While <application>PL/Perl</> functions run in a separate Perl
695+
interpreter for each SQL role, all <application>PL/PerlU</> functions
696+
executed in a given session run in a single Perl interpreter (which is
697+
not any of the ones used for <application>PL/Perl</> functions).
698+
This allows <application>PL/PerlU</> functions to share data freely,
699+
but no communication can occur between <application>PL/Perl</> and
700+
<application>PL/PerlU</> functions.
701+
</para>
702+
</note>
703+
704+
<note>
705+
<para>
706+
Perl cannot support multiple interpreters within one process unless
707+
it was built with the appropriate flags, namely either
708+
<literal>usemultiplicity</> or <literal>useithreads</>.
709+
(<literal>usemultiplicity</> is preferred unless you actually need
710+
to use threads. For more details, see the
711+
<citerefentry><refentrytitle>perlembed</></citerefentry> man page.)
712+
If <application>PL/Perl</> is used with a copy of Perl that was not built
713+
this way, then it is only possible to have one Perl interpreter per
714+
session, and so any one session can only execute either
715+
<application>PL/PerlU</> functions, or <application>PL/Perl</> functions
716+
that are all called by the same SQL role.
717+
</para>
691718
</note>
692719

693720
</sect1>

‎doc/src/sgml/pltcl.sgml

Lines changed: 34 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -215,14 +215,36 @@ $$ LANGUAGE pltcl;
215215
Sometimes it
216216
is useful to have some global data that is held between two
217217
calls to a function or is shared between different functions.
218-
This is easily done since
219-
all PL/Tcl functions executed in one session share the same
220-
safe Tcl interpreter. So, any global Tcl variable is accessible to
221-
all PL/Tcl function calls and will persist for the duration of the
222-
SQL session. (Note that <application>PL/TclU</> functions likewise share
223-
global data, but they are in a different Tcl interpreter and cannot
224-
communicate with PL/Tcl functions.)
218+
This is easily done in PL/Tcl, but there are some restrictions that
219+
must be understood.
225220
</para>
221+
222+
<para>
223+
For security reasons, PL/Tcl executes functions called by any one SQL
224+
role in a separate Tcl interpreter for that role. This prevents
225+
accidental or malicious interference by one user with the behavior of
226+
another user's PL/Tcl functions. Each such interpreter will have its own
227+
values for any <quote>global</> Tcl variables. Thus, two PL/Tcl
228+
functions will share the same global variables if and only if they are
229+
executed by the same SQL role. In an application wherein a single
230+
session executes code under multiple SQL roles (via <literal>SECURITY
231+
DEFINER</> functions, use of <command>SET ROLE</>, etc) you may need to
232+
take explicit steps to ensure that PL/Tcl functions can share data. To
233+
do that, make sure that functions that should communicate are owned by
234+
the same user, and mark them <literal>SECURITY DEFINER</>. You must of
235+
course take care that such functions can't be used to do anything
236+
unintended.
237+
</para>
238+
239+
<para>
240+
All PL/TclU functions used in a session execute in the same Tcl
241+
interpreter, which of course is distinct from the interpreter(s)
242+
used for PL/Tcl functions. So global data is automatically shared
243+
between PL/TclU functions. This is not considered a security risk
244+
because all PL/TclU functions execute at the same trust level,
245+
namely that of a database superuser.
246+
</para>
247+
226248
<para>
227249
To help protect PL/Tcl functions from unintentionally interfering
228250
with each other, a global
@@ -232,7 +254,9 @@ $$ LANGUAGE pltcl;
232254
<literal>GD</> be used
233255
for persistent private data of a function. Use regular Tcl global
234256
variables only for values that you specifically intend to be shared among
235-
multiple functions.
257+
multiple functions. (Note that the <literal>GD</> arrays are only
258+
global within a particular interpreter, so they do not bypass the
259+
security restrictions mentioned above.)
236260
</para>
237261

238262
<para>
@@ -688,8 +712,8 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
688712
exists, the module <literal>unknown</> is fetched from the table
689713
and loaded into the Tcl interpreter immediately before the first
690714
execution of a PL/Tcl function in a database session. (This
691-
happens separately for PL/Tcl and PL/TclU, if both are used,
692-
because separate interpreters are used for the two languages.)
715+
happens separately for each Tcl interpreter, if more than one is
716+
used in a session; see <xref linkend="pltcl-global">.)
693717
</para>
694718
<para>
695719
While the <literal>unknown</> module could actually contain any

‎doc/src/sgml/release-7.4.sgml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,43 @@
3737

3838
<itemizedlist>
3939

40+
<listitem>
41+
<para>
42+
Use a separate interpreter for each calling SQL userid in PL/Perl and
43+
PL/Tcl (Tom Lane)
44+
</para>
45+
46+
<para>
47+
This change prevents security problems that can be caused by subverting
48+
Perl or Tcl code that will be executed later in the same session under
49+
another SQL user identity (for example, within a <literal>SECURITY
50+
DEFINER</> function). Most scripting languages offer numerous ways that
51+
that might be done, such as redefining standard functions or operators
52+
called by the target function. Without this change, any SQL user with
53+
Perl or Tcl language usage rights can do essentially anything with the
54+
SQL privileges of the target function's owner.
55+
</para>
56+
57+
<para>
58+
The cost of this change is that intentional communication among Perl
59+
and Tcl functions becomes more difficult. To provide an escape hatch,
60+
PL/PerlU and PL/TclU functions continue to use only one interpreter
61+
per session. This is not considered a security issue since all such
62+
functions execute at the trust level of a database superuser already.
63+
</para>
64+
65+
<para>
66+
It is likely that third-party procedural languages that claim to offer
67+
trusted execution have similar security issues. We advise contacting
68+
the authors of any PL you are depending on for security-critical
69+
purposes.
70+
</para>
71+
72+
<para>
73+
Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433).
74+
</para>
75+
</listitem>
76+
4077
<listitem>
4178
<para>
4279
Prevent possible crashes in <function>pg_get_expr()</> by disallowing

‎doc/src/sgml/release-8.0.sgml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,43 @@
3737

3838
<itemizedlist>
3939

40+
<listitem>
41+
<para>
42+
Use a separate interpreter for each calling SQL userid in PL/Perl and
43+
PL/Tcl (Tom Lane)
44+
</para>
45+
46+
<para>
47+
This change prevents security problems that can be caused by subverting
48+
Perl or Tcl code that will be executed later in the same session under
49+
another SQL user identity (for example, within a <literal>SECURITY
50+
DEFINER</> function). Most scripting languages offer numerous ways that
51+
that might be done, such as redefining standard functions or operators
52+
called by the target function. Without this change, any SQL user with
53+
Perl or Tcl language usage rights can do essentially anything with the
54+
SQL privileges of the target function's owner.
55+
</para>
56+
57+
<para>
58+
The cost of this change is that intentional communication among Perl
59+
and Tcl functions becomes more difficult. To provide an escape hatch,
60+
PL/PerlU and PL/TclU functions continue to use only one interpreter
61+
per session. This is not considered a security issue since all such
62+
functions execute at the trust level of a database superuser already.
63+
</para>
64+
65+
<para>
66+
It is likely that third-party procedural languages that claim to offer
67+
trusted execution have similar security issues. We advise contacting
68+
the authors of any PL you are depending on for security-critical
69+
purposes.
70+
</para>
71+
72+
<para>
73+
Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433).
74+
</para>
75+
</listitem>
76+
4077
<listitem>
4178
<para>
4279
Prevent possible crashes in <function>pg_get_expr()</> by disallowing

‎doc/src/sgml/release-8.1.sgml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,43 @@
3737

3838
<itemizedlist>
3939

40+
<listitem>
41+
<para>
42+
Use a separate interpreter for each calling SQL userid in PL/Perl and
43+
PL/Tcl (Tom Lane)
44+
</para>
45+
46+
<para>
47+
This change prevents security problems that can be caused by subverting
48+
Perl or Tcl code that will be executed later in the same session under
49+
another SQL user identity (for example, within a <literal>SECURITY
50+
DEFINER</> function). Most scripting languages offer numerous ways that
51+
that might be done, such as redefining standard functions or operators
52+
called by the target function. Without this change, any SQL user with
53+
Perl or Tcl language usage rights can do essentially anything with the
54+
SQL privileges of the target function's owner.
55+
</para>
56+
57+
<para>
58+
The cost of this change is that intentional communication among Perl
59+
and Tcl functions becomes more difficult. To provide an escape hatch,
60+
PL/PerlU and PL/TclU functions continue to use only one interpreter
61+
per session. This is not considered a security issue since all such
62+
functions execute at the trust level of a database superuser already.
63+
</para>
64+
65+
<para>
66+
It is likely that third-party procedural languages that claim to offer
67+
trusted execution have similar security issues. We advise contacting
68+
the authors of any PL you are depending on for security-critical
69+
purposes.
70+
</para>
71+
72+
<para>
73+
Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433).
74+
</para>
75+
</listitem>
76+
4077
<listitem>
4178
<para>
4279
Prevent possible crashes in <function>pg_get_expr()</> by disallowing

‎doc/src/sgml/release-8.2.sgml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,43 @@
3131

3232
<itemizedlist>
3333

34+
<listitem>
35+
<para>
36+
Use a separate interpreter for each calling SQL userid in PL/Perl and
37+
PL/Tcl (Tom Lane)
38+
</para>
39+
40+
<para>
41+
This change prevents security problems that can be caused by subverting
42+
Perl or Tcl code that will be executed later in the same session under
43+
another SQL user identity (for example, within a <literal>SECURITY
44+
DEFINER</> function). Most scripting languages offer numerous ways that
45+
that might be done, such as redefining standard functions or operators
46+
called by the target function. Without this change, any SQL user with
47+
Perl or Tcl language usage rights can do essentially anything with the
48+
SQL privileges of the target function's owner.
49+
</para>
50+
51+
<para>
52+
The cost of this change is that intentional communication among Perl
53+
and Tcl functions becomes more difficult. To provide an escape hatch,
54+
PL/PerlU and PL/TclU functions continue to use only one interpreter
55+
per session. This is not considered a security issue since all such
56+
functions execute at the trust level of a database superuser already.
57+
</para>
58+
59+
<para>
60+
It is likely that third-party procedural languages that claim to offer
61+
trusted execution have similar security issues. We advise contacting
62+
the authors of any PL you are depending on for security-critical
63+
purposes.
64+
</para>
65+
66+
<para>
67+
Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433).
68+
</para>
69+
</listitem>
70+
3471
<listitem>
3572
<para>
3673
Prevent possible crashes in <function>pg_get_expr()</> by disallowing

‎doc/src/sgml/release-8.3.sgml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,43 @@
3131

3232
<itemizedlist>
3333

34+
<listitem>
35+
<para>
36+
Use a separate interpreter for each calling SQL userid in PL/Perl and
37+
PL/Tcl (Tom Lane)
38+
</para>
39+
40+
<para>
41+
This change prevents security problems that can be caused by subverting
42+
Perl or Tcl code that will be executed later in the same session under
43+
another SQL user identity (for example, within a 103E0 <literal>SECURITY
44+
DEFINER</> function). Most scripting languages offer numerous ways that
45+
that might be done, such as redefining standard functions or operators
46+
called by the target function. Without this change, any SQL user with
47+
Perl or Tcl language usage rights can do essentially anything with the
48+
SQL privileges of the target function's owner.
49+
</para>
50+
51+
<para>
52+
The cost of this change is that intentional communication among Perl
53+
and Tcl functions becomes more difficult. To provide an escape hatch,
54+
PL/PerlU and PL/TclU functions continue to use only one interpreter
55+
per session. This is not considered a security issue since all such
56+
functions execute at the trust level of a database superuser already.
57+
</para>
58+
59+
<para>
60+
It is likely that third-party procedural languages that claim to offer
61+
trusted execution have similar security issues. We advise contacting
62+
the authors of any PL you are depending on for security-critical
63+
purposes.
64+
</para>
65+
66+
<para>
67+
Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433).
68+
</para>
69+
</listitem>
70+
3471
<listitem>
3572
<para>
3673
Prevent possible crashes in <function>pg_get_expr()</> by disallowing

0 commit comments

Comments
 (0)
0