pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Block environment variable mutations from trusted PL/Perl.
7+ messages / 1 participants
[nested] [flat]
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/b7e3a52a877cffb42ec7208232e30a8e44231e01
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 | 24 +++++++++++++++
7 files changed, 176 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/8fe3e697a1a83a722b107c7cb9c31084e1f4d077
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e530835c6cc5b2dbf330ebe6b0a7fb9f19f5a54c
Modified Files
--------------
doc/src/sgml/plperl.sgml | 13 ++++++++
src/pl/plperl/GNUmakefile | 4 +--
src/pl/plperl/expected/plperl_env.out | 53 ++++++++++++++++++++++++++++++++
src/pl/plperl/plc_trusted.pl | 24 +++++++++++++++
src/pl/plperl/sql/plperl_env.sql | 58 +++++++++++++++++++++++++++++++++++
src/test/regress/regress.c | 23 ++++++++++++++
6 files changed, 173 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d15ec27c977100037ae513ab7fe1a214bfc2507b
Modified Files
--------------
doc/src/sgml/plperl.sgml | 13 +++++++++
src/pl/plperl/GNUmakefile | 4 +--
src/pl/plperl/input/plperl_env.source | 52 ++++++++++++++++++++++++++++++++++
src/pl/plperl/output/plperl_env.source | 49 ++++++++++++++++++++++++++++++++
src/pl/plperl/plc_trusted.pl | 24 ++++++++++++++++
src/test/regress/regress.c | 24 ++++++++++++++++
6 files changed, 164 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e428cd058f0bebb5782b0c263565b0ad088e9650
Modified Files
--------------
doc/src/sgml/plperl.sgml | 13 +++++++++
src/pl/plperl/GNUmakefile | 4 +--
src/pl/plperl/input/plperl_env.source | 52 ++++++++++++++++++++++++++++++++++
src/pl/plperl/output/plperl_env.source | 49 ++++++++++++++++++++++++++++++++
src/pl/plperl/plc_trusted.pl | 24 ++++++++++++++++
src/test/regress/regress.c | 24 ++++++++++++++++
6 files changed, 164 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Block environment variable mutations from trusted PL/Perl.
@ 2024-11-11 14:26 Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 7+ messages in thread
From: Noah Misch @ 2024-11-11 14:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/2ab12d860e51e468703a2777b3759b7a61639df2
Modified Files
--------------
doc/src/sgml/plperl.sgml | 13 +++++++++
src/pl/plperl/GNUmakefile | 4 +--
src/pl/plperl/input/plperl_env.source | 52 ++++++++++++++++++++++++++++++++++
src/pl/plperl/output/plperl_env.source | 49 ++++++++++++++++++++++++++++++++
src/pl/plperl/plc_trusted.pl | 24 ++++++++++++++++
src/test/regress/regress.c | 24 ++++++++++++++++
6 files changed, 164 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-11-11 14:26 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
2024-11-11 14:26 pgsql: Block environment variable mutations from trusted PL/Perl. Noah Misch <noah@leadboat.com>
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