Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 603720 - <dev-db/postgresql-{9.2.20-r1,9.3.16-r1,9.4.11-r1,9.5.6-r1,9.6.2-r1}: Denial of Service via init script reload command
Summary: <dev-db/postgresql-{9.2.20-r1,9.3.16-r1,9.4.11-r1,9.5.6-r1,9.6.2-r1}: Denial ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [glsa+]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-25 21:06 UTC by Michael Orlitzky
Modified: 2018-10-30 21:08 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/etc/init.d/postgresql-9.5 (postgresql-9.5,5.00 KB, text/plain)
2017-01-02 19:46 UTC, Aaron W. Swenson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2016-12-25 21:06:24 UTC
The "reload" command in the postgres init script gets its PID from the postmaster.pid file in postgresql's ${DATA_DIR}:

  reload() {
    ebegin "Reloading PostgreSQL configuration"
    kill -HUP $(head -n1 ${DATA_DIR%/}/postmaster.pid)
    eend $?
  }

However, $DATA_DIR is owned by the postgres user. From the ebuild:

  einfo "Creating the data directory ..."
  if [[ ${EUID} == 0 ]] ; then
    mkdir -p "${DATA_DIR}"
    chown -Rf postgres:postgres "${DATA_DIR}"
    chmod 0700 "${DATA_DIR}"
  fi

As a result, the postgres user can place any PID in postmaster.pid, and have root send a SIGHUP to it. That can, for example, be used to kill processes started from a terminal; I tested it with a root emacs session.
Comment 1 Aaron W. Swenson gentoo-dev 2016-12-30 17:26:02 UTC
The database superusers can read from or write to any file or directory on the system that the postgres system user has permissions to do so via the COPY statement (https://www.postgresql.org/docs/current/static/sql-copy.html). As this is done via the client interface, remote access is possible. However, exposure is minimal as there should only be vetted individuals with superuser rights within the database.

We can have the kill command executed as the postgres system user (or even switch to the equivalent 'pg_ctl reload' command, still executed as the postgres system user). We'll still have to read the ${DATA_DIR%/}/postmaster.pid file, but the most damage it could do is instruct some PostgreSQL server to reread its configuration files.

Is this a suitable resolution?
Comment 2 Michael Orlitzky gentoo-dev 2016-12-30 21:58:58 UTC
(In reply to Aaron W. Swenson from comment #1)
> 
> We can have the kill command executed as the postgres system user (or even
> switch to the equivalent 'pg_ctl reload' command, still executed as the
> postgres system user). We'll still have to read the
> ${DATA_DIR%/}/postmaster.pid file, but the most damage it could do is
> instruct some PostgreSQL server to reread its configuration files.
> 
> Is this a suitable resolution?

That sounds good to me. I'll have to double-check what start-stop-daemon is doing to make sure that start() and stop() don't have related problems.
Comment 3 Aaron W. Swenson gentoo-dev 2016-12-31 15:42:34 UTC
(In reply to Michael Orlitzky from comment #2)
> (In reply to Aaron W. Swenson from comment #1)
> > 
> > We can have the kill command executed as the postgres system user (or even
> > switch to the equivalent 'pg_ctl reload' command, still executed as the
> > postgres system user). We'll still have to read the
> > ${DATA_DIR%/}/postmaster.pid file, but the most damage it could do is
> > instruct some PostgreSQL server to reread its configuration files.
> > 
> > Is this a suitable resolution?
> 
> That sounds good to me. I'll have to double-check what start-stop-daemon is
> doing to make sure that start() and stop() don't have related problems.

I have to add the --user flag to the start-stop-daemon in stop().

I may even opt for dropping start-stop-daemon altogether to use pg_ctl directly as it has checks for the validity of the postmaster.pid file.
Comment 4 Aaron W. Swenson gentoo-dev 2017-01-02 19:46:37 UTC
Created attachment 458412 [details]
/etc/init.d/postgresql-9.5

Attached is the proposed initscript to resolve this particular security issue and others. (This one is specifically for 9.5, but all slots 9.3 and above use initscript template. 9.2 will need a slightly modified version.)

We've switched to using pg_ctl instead of start-stop-daemon as pg_ctl has additional checks to make sure the PID file is properly formatted as the file contains more than just the process ID. Each call to pg_ctl is done as the postgres system user.

In practice, the potential for denial of service is minimal. The only individuals that have access to the files are the vetted database superusers, who are most likely the database administrator(s). The initscript can only be executed by root and cannot be invoked through PostgreSQL, and must be done within a minute or so of the change happening before the PostgreSQL server that originally created the PID file shuts itself down in an effort to avoid data corruption from a potentially competing instance.
Comment 5 Aaron W. Swenson gentoo-dev 2017-04-20 15:27:34 UTC
The fixes have been committed, but I've been vague on the reason.

commit f1b07f8816c2f0346d07468bdb4c5b9ce4ffada7
Author: Aaron W. Swenson <titanofold@gentoo.org>
Date:   Mon Apr 17 09:09:56 2017 -0400

    dev-db/postgresql: Eselect and security related fixes
    
    Dependency bumped on app-eselect/eselect-postgresql to 2.0. Some of
    its work has been shifted into the ebuild as the files/links don’t
    change until this package is reemerge, unmerged, or updated.
    
    Security issues addressed in the initscripts per bugs 603716 and 603720.
    
    Bugs: 603716, 603720
Comment 6 Michael Orlitzky gentoo-dev 2017-08-16 13:55:26 UTC
Security team: this has been fixed, and the new versions are stabilized. Should I just resolve this as fixed, or do you want to go through the whole public security bug process?
Comment 7 Kristian Fiskerstrand gentoo-dev Security 2017-08-16 14:02:03 UTC
(In reply to Michael Orlitzky from comment #6)
> Security team: this has been fixed, and the new versions are stabilized.
> Should I just resolve this as fixed, or do you want to go through the whole
> public security bug process?

The latter, as far as I can see as a Denial of Service. What is the basis of the init script; is it Gentoo-specific or is there anyone to alert with similar issues? The issue likely requires a CVE in either case, so would be useful with scoping for the CVE request.
Comment 8 Kristian Fiskerstrand gentoo-dev Security 2017-08-16 14:03:56 UTC
(In reply to Kristian Fiskerstrand from comment #7)
> (In reply to Michael Orlitzky from comment #6)
> > Security team: this has been fixed, and the new versions are stabilized.
> > Should I just resolve this as fixed, or do you want to go through the whole
> > public security bug process?
> 
> The latter, as far as I can see as a Denial of Service. What is the basis of
> the init script; is it Gentoo-specific or is there anyone to alert with
> similar issues? The issue likely requires a CVE in either case, so would be
> useful with scoping for the CVE request.

... This also extends to which version the issue was introduced in and which version it was fixed in.
Comment 9 Michael Orlitzky gentoo-dev 2017-08-16 14:16:18 UTC
(In reply to Kristian Fiskerstrand from comment #7)
> 
> The latter, as far as I can see as a Denial of Service. What is the basis of
> the init script; is it Gentoo-specific or is there anyone to alert with
> similar issues? The issue likely requires a CVE in either case, so would be
> useful with scoping for the CVE request.

The important question is, is there anyone else using an init script that trusts the postgresql PID file?

In most cases, a daemon writes a PID file, and you (i.e. root, the init system) are supposed to figure out what to do with it. And if you trust a PID file that is writable by a non-root user, you're vulnerable.

The old Gentoo init script used start-stop-daemon to manage the daemon. It trusts the PID file, and that was why our init script was vulnerable. However, upstream's official way of managing the daemon is through pg_ctl, which performs additional checks on the PID to ensure that it actually is the postgres daemon. Thus if you're using pg_ctl in your init scripts, you should be fine.

The scripts that come with postgres are all OK:

  https://github.com/postgres/postgres/tree/master/contrib/start-scripts

So any vulnerable init scripts would be buried in somebody else's repos.
Comment 10 Kristian Fiskerstrand gentoo-dev Security 2017-08-16 17:03:22 UTC
(In reply to Kristian Fiskerstrand from comment #8)
> (In reply to Kristian Fiskerstrand from comment #7)
> > (In reply to Michael Orlitzky from comment #6)
> > > Security team: this has been fixed, and the new versions are stabilized.
> > > Should I just resolve this as fixed, or do you want to go through the whole
> > > public security bug process?
> > 
> > The latter, as far as I can see as a Denial of Service. What is the basis of
> > the init script; is it Gentoo-specific or is there anyone to alert with
> > similar issues? The issue likely requires a CVE in either case, so would be
> > useful with scoping for the CVE request.
> 
> ... This also extends to which version the issue was introduced in and which
> version it was fixed in.

@maintainers: Maybe you can help out on this, as far as I see the fixes are in versions listed by $ git diff-tree --no-commit-id --name-only -r f1b07f8816c2f0346d07468bdb4c5b9ce4ffada7 , i.e
dev-db/postgresql/postgresql-9.2.20-r1.ebuild
dev-db/postgresql/postgresql-9.3.16-r1.ebuild
dev-db/postgresql/postgresql-9.4.11-r1.ebuild
dev-db/postgresql/postgresql-9.5.6-r1.ebuild
dev-db/postgresql/postgresql-9.6.2-r1.ebuild

As far as I can tell, the following versions and arches are missing stabilization for the various slots:
9.2: hppa
9.3: hppa
9.4: alpha hppa
9.5: hppa

Can you please indicate which version the init script got added?
Comment 11 Aaron W. Swenson gentoo-dev 2017-08-17 13:01:51 UTC
(In reply to Kristian Fiskerstrand from comment #10)
> (In reply to Kristian Fiskerstrand from comment #8)
> > (In reply to Kristian Fiskerstrand from comment #7)
> > > (In reply to Michael Orlitzky from comment #6)
> > > > Security team: this has been fixed, and the new versions are stabilized.
> > > > Should I just resolve this as fixed, or do you want to go through the whole
> > > > public security bug process?
> > > 
> > > The latter, as far as I can see as a Denial of Service. What is the basis of
> > > the init script; is it Gentoo-specific or is there anyone to alert with
> > > similar issues? The issue likely requires a CVE in either case, so would be
> > > useful with scoping for the CVE request.
> > 
> > ... This also extends to which version the issue was introduced in and which
> > version it was fixed in.
> 
> @maintainers: Maybe you can help out on this, as far as I see the fixes are
> in versions listed by $ git diff-tree --no-commit-id --name-only -r
> f1b07f8816c2f0346d07468bdb4c5b9ce4ffada7 , i.e
> dev-db/postgresql/postgresql-9.2.20-r1.ebuild
> dev-db/postgresql/postgresql-9.3.16-r1.ebuild
> dev-db/postgresql/postgresql-9.4.11-r1.ebuild
> dev-db/postgresql/postgresql-9.5.6-r1.ebuild
> dev-db/postgresql/postgresql-9.6.2-r1.ebuild
> 
> As far as I can tell, the following versions and arches are missing
> stabilization for the various slots:
> 9.2: hppa
> 9.3: hppa
> 9.4: alpha hppa
> 9.5: hppa
> 
> Can you please indicate which version the init script got added?

Those are the correct versions. I haven't been able to remove the affected versions yet because of HPPA lagging behind.

Alpha must have missed 9.4. They shouldn't be stabilizing 9.5 on up.
Comment 12 Michael Orlitzky gentoo-dev 2017-11-08 14:26:05 UTC
Alpha caught the missing 9.4 stabilization, so now we just need hppa on the 9.2, 9.3, 9.4, and 9.5 slots.
Comment 13 Aaron W. Swenson gentoo-dev 2018-02-11 15:56:50 UTC
commit 850efe2a5700c2ba30f9e9860dd83143cf15da34 (HEAD -> master, origin/master, origin/HEAD)
Author: Aaron W. Swenson <titanofold@gentoo.org>
Date:   Sun Feb 11 10:54:10 2018 -0500

    dev-db/postgresql: Cleanup Old and Insecure Files

    Bug: https://bugs.gentoo.org/627462
    Bug: https://bugs.gentoo.org/636978
    Bug: https://bugs.gentoo.org/630824
    Bug: https://bugs.gentoo.org/603720
    Bug: https://bugs.gentoo.org/603716
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

commit 3b3ec30d0b02920ec76eeef4db2a968c3a907d23
Author: Jeroen Roovers <jer@gentoo.org>
Date:   Sun Feb 11 13:09:46 2018 +0100

    dev-db/postgresql: Stable for HPPA too.

    Package-Manager: Portage-2.3.24, Repoman-2.3.6
    RepoMan-Options: --ignore-arches
Comment 14 Aaron W. Swenson gentoo-dev 2018-05-20 09:51:33 UTC
This has been  completed 3 months ago now. What's our next step to closed this bug?
Comment 15 Thomas Deutschmann gentoo-dev Security 2018-10-30 19:12:47 UTC
Converting into security bug.
Bug is now public.

Added to an existing GLSA.
Comment 16 GLSAMaker/CVETool Bot gentoo-dev 2018-10-30 21:08:42 UTC
This issue was resolved and addressed in
 GLSA 201810-08 at https://security.gentoo.org/glsa/201810-08
by GLSA coordinator Thomas Deutschmann (whissi).