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 of Service via init script reload command | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Michael Orlitzky <mjo> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | minor | CC: | patrick, titanofold | ||||
Priority: | Normal | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | B3 [glsa+] | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
Michael Orlitzky
2016-12-25 21:06:24 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? (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. (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. 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.
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 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? (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. (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. (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. (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? (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. 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. 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 This has been completed 3 months ago now. What's our next step to closed this bug? Converting into security bug. Bug is now public. Added to an existing GLSA. This issue was resolved and addressed in GLSA 201810-08 at https://security.gentoo.org/glsa/201810-08 by GLSA coordinator Thomas Deutschmann (whissi). |