[YSQL] Import specially treated variables fix #14139
Assignees
Labels
2.14 Backport Required
area/ysql
Yugabyte SQL (YSQL)
kind/bug
This issue is a bug
priority/medium
Medium priority issue
Comments
tedyu
added
area/ysql
yugabyte-ci
added
kind/bug
sushantrmishra
added
2.12 Backport Required
2.14 Backport Required
and removed
status/awaiting-triage
tedyu
added a commit
that referenced
this issue
Sep 24, 2022
…variables
Summary:
Upstream commit was 098fb00799ffb026ff12c64bd21635f963cfc609
Commit message was:
If an interactive psql session used \gset when querying a compromised
server, the attacker could execute arbitrary code as the operating
system account running psql. Using a prefix not found among specially
treated variables, e.g. every lowercase string, precluded the attack.
Fix by issuing a warning and setting no variable for the column in
question. Users wanting the old behavior can use a prefix and then a
meta-command like "\set HISTSIZE :prefix_HISTSIZE". Back-patch to 9.5
(all supported versions).
Reviewed by Robert Haas. Reported by Nick Cleaton.
Security: CVE-2020-25696
The call to pg_log_warning() is omitted since it fails compilation:
```
[2022-09-22T15:26:00.821Z] src/postgres/src/bin/psql/common.c:935:5: error: implicit declaration of function 'pg_log_warning' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
[2022-09-22T15:26:00.821Z] pg_log_warning("attempt to \\gset into specially treated variable \"%s\" ignored",
```
Porting over pg_log_warning would require several other commits.
Test Plan:
```
yugabyte=# select 97 as "EOF", 'ok' as _foo \gset IGNORE
yugabyte=# \echo :IGNORE_foo :IGNOREEOF
ok 0
```
Reviewers: plee, smishra, myang
Reviewed By: myang
Subscribers: yql
Differential Revision: https://phabricator.dev.yugabyte.com/D19723
tedyu
added a commit
that referenced
this issue
Sep 26, 2022
… specially treated variables Summary: Original commit was a2bfda3 / D19723 Upstream commit was 098fb00799ffb026ff12c64bd21635f963cfc609 Commit message was: If an interactive psql session used \gset when querying a compromised server, the attacker could execute arbitrary code as the operating system account running psql. Using a prefix not found among specially treated variables, e.g. every lowercase string, precluded the attack. Fix by issuing a warning and setting no variable for the column in question. Users wanting the old behavior can use a prefix and then a meta-command like "\set HISTSIZE :prefix_HISTSIZE". Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Nick Cleaton. Security: CVE-2020-25696 Test Plan: Jenkins: rebase: 2.14 Reviewers: myang Reviewed By: myang Subscribers: yql Differential Revision: https://phabricator.dev.yugabyte.com/D19778
tedyu
added a commit
that referenced
this issue
Sep 26, 2022
… specially treated variables Summary: Original commit was a2bfda3 / D19723 Upstream commit was 098fb00799ffb026ff12c64bd21635f963cfc609 Commit message was: If an interactive psql session used \gset when querying a compromised server, the attacker could execute arbitrary code as the operating system account running psql. Using a prefix not found among specially treated variables, e.g. every lowercase string, precluded the attack. Fix by issuing a warning and setting no variable for the column in question. Users wanting the old behavior can use a prefix and then a meta-command like "\set HISTSIZE :prefix_HISTSIZE". Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Nick Cleaton. Security: CVE-2020-25696 Test Plan: Jenkins: rebase: 2.12 Reviewers: myang Reviewed By: myang Subscribers: yql Differential Revision: https://phabricator.dev.yugabyte.com/D19779
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-3615
Description
Import specially treated variables fix
The text was updated successfully, but these errors were encountered: