PostgreSQL runs under a non-root operating system account, and database superusers have effective ability to run arbitrary code under that system account. PostgreSQL provides a script for starting the database server during system boot. Packages of PostgreSQL for many operating systems provide their own, packager-authored startup implementations. Several implementations use a log file name that the database superuser can replace with a symbolic link. As root, the scripts redirect stdout and stderr content to the log file name. This often suffices for the database superuser to escalate to root privileges when root starts the server. Supported, Vulnerable Versions: 9.2 - 10
Acknowledgments: Name: the PostgreSQL project Upstream: Antoine Scemama (Brainloop)
Created attachment 1342437 [details] Upstream fix (for upstream-version of scripting)
The issue that was reported for the init script included with the upstream PosgreSQL sources is here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=contrib/start-scripts/linux;h=763a8064#l95 su - $PGUSER -c "$DAEMON_ENV $DAEMON -D '$PGDATA' &" >>$PGLOG 2>&1 The problem is that redirection to / opening of the log file is done with the privileges of the user running the init script (i.e. root) and not as postgres user. Hence postgres user can cause postmaster process output to be written to an arbitrary file via a $PGLOG link. The same pattern in used in the "start" action of the init script as used in postgresql packages in Red Hat Enterprise Linux 6 and earlier. It was also used in earlier Fedora versions prior to introduction of systemd: http://pkgs.fedoraproject.org/cgit/rpms/postgresql.git/tree/postgresql.init?h=f7#n181 $SU -l postgres -c "$PGENGINE/postmaster -p '$PGPORT' -D '$PGDATA' ${PGOPTS} &" >> "$PGLOG" 2>&1 < /dev/null Additionally, the similar pattern can also be found in the "initdb" action of the same init script: http://pkgs.fedoraproject.org/cgit/rpms/postgresql.git/tree/postgresql.init?h=f7#n247 $SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident sameuser'" >> "$PGLOG" 2>&1 < /dev/null The init script as used in postgresql packages in Red Hat Software Collections for Red Hat Enterprise Linux 6 does not contain this pattern directly. However, as part of its "start" action, it calls the run_cmd_as_dbadmin() function from the postgresql-setup. This function does unsafe output redirection, even though the code looks somewhat different: https://github.com/devexp-db/postgresql-setup/blob/v5.1/share/postgresql-setup/library.sh.in#L135-L137 test -n "$stdout" && exec >>"$stdout" test -n "$stderr" && exec 2>>"$stderr" $SU_POSTGRES -c "$cmd" < /dev/null The postgresql packages for Red Hat Enterprise Linux 7 do not use init script to start the service, but rather use systemd service unit file. This file does not contain this pattern, nor call the run_cmd_as_dbadmin() function. Additionally, all commands executed by the service file are already started with the postgres user privileges, so there's no possibility of privilege escalation. The postgresql packages in Red Hat Enterprise Linux 7 and Red Hat Software Collections for Red Hat Enterprise Linux 6 and 7 also contain their own variant of the "initdb" instance of this problem. The code is found in the postgresql-setup script: https://github.com/devexp-db/postgresql-setup/blob/v5.1/postgresql-setup.in#L148 $SU_POSTGRES -c "$initdbcmd" >> "$initdb_log" 2>&1 < /dev/null The code is reached when the script is executed with --initdb or --upgrade options. On Red Hat Software Collections for Red Hat Enterprise Linux 6, the init script invokes the postgresql-setup with these options from the "inidb" and "upgrade" actions. Note that the instances of the problem that are executed during the service start are more likely to be exploited, as "initdb" and "upgrade" actions are only used rarely - possibly only once before the specific PostgreSQL installation is first started and hence prior to giving database administrator privileges to any non-root user.
Upstream commit: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dfc015dcf46c1996bd7ed5866e9e045d258604b3
External References: https://www.postgresql.org/about/news/1801/
Created mingw-postgresql tracking bugs for this issue: Affects: epel-7 [bug 1516000] Affects: fedora-all [bug 1515999] Created postgresql tracking bugs for this issue: Affects: fedora-all [bug 1516002]
Commit addressing this issue in postgresql-setup: https://github.com/devexp-db/postgresql-setup/commit/86e6bb803775f889a3f100811b7038a3f4eb8519
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:3402 https://access.redhat.com/errata/RHSA-2017:3402
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Via RHSA-2017:3403 https://access.redhat.com/errata/RHSA-2017:3403
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Via RHSA-2017:3404 https://access.redhat.com/errata/RHSA-2017:3404
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Via RHSA-2017:3405 https://access.redhat.com/errata/RHSA-2017:3405
Statement: Red Hat Enterprise Linux 6 and Satellite 5 are now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.