Block environment variable mutations from trusted PL/Perl.
Many process environment variables (e.g. PATH), bypass the containment
expected of a trusted PL. Hence, trusted PLs must not offer features
that achieve setenv(). Otherwise, an attacker having USAGE privilege on
the language often can achieve arbitrary code execution, even if the
attacker lacks a database server operating system user.
To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just
replaces each modification attempt with a warning. Sites that reach
these warnings should evaluate the application-specific implications of
proceeding without the environment modification:
Can the application reasonably proceed without the modification?
If no, switch to plperlu or another approach.
If yes, the application should change the code to stop attempting
environment modifications. If that's too difficult, add "untie
%main::ENV" in any code executed before the warning. For example,
one might add it to the start of the affected function or even to
the plperl.on_plperl_init setting.
In passing, link to Perl's guidance about the Perl features behind the
security posture of PL/Perl.
Back-patch to v12 (all supported versions).
Andrew Dunstan and Noah Misch
Security: CVE-2024-10979
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/3ebcfa54db3309651d8f1d3be6451a8449f6c6ec
Modified Files
--------------
doc/src/sgml/plperl.sgml | 13 ++++++++
src/pl/plperl/GNUmakefile | 4 +--
src/pl/plperl/expected/plperl_env.out | 53 ++++++++++++++++++++++++++++++++
src/pl/plperl/meson.build | 2 ++
src/pl/plperl/plc_trusted.pl | 24 +++++++++++++++
src/pl/plperl/sql/plperl_env.sql | 58 +++++++++++++++++++++++++++++++++++
src/test/regress/regress.c | 23 ++++++++++++++
7 files changed, 175 insertions(+), 2 deletions(-)
