Bug 22002 - postgresql new security issues CVE-2017-12172 and CVE-2017-1509[89]
Summary: postgresql new security issues CVE-2017-12172 and CVE-2017-1509[89]
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-64-OK
Keywords: advisory, has_procedure, validated_update
Depends on:
Blocks:
 
Reported: 2017-11-10 01:58 CET by David Walser
Modified: 2017-11-29 19:53 CET (History)
5 users (show)

See Also:
Source RPM: postgresql9.3, postgresql9.4, postgresql9.6
CVE:
Status comment:


Attachments

Description David Walser 2017-11-10 01:58:12 CET
Upstream has released new versions today (November 9):
https://www.postgresql.org/about/news/1801/

The issues are fixed in 9.3.20, 9.4.15, and 9.6.6.

Mageia 5 is also affected.

Updated packages uploaded for Mageia 5 and Mageia 6.

Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=18103#c6

Advisory:
========================

Updated postgresql packages fix security vulnerabilities:

The startup log file for the postmaster (in newer releases, "postgres")
process was opened while the process was still owned by root. With this setup,
the database owner could specify a file that they did not have access to and
cause the file to be corrupted with logged data (CVE-2017-12172).

Crash due to rowtype mismatch in json{b}_populate_recordset(). These functions
used the result rowtype specified in the FROM ... AS clause without checking
that it matched the actual rowtype of the supplied tuple value. If it didn't,
that would usually result in a crash, though disclosure of server memory
contents seems possible as well (CVE-2017-15098).

The "INSERT ... ON CONFLICT DO UPDATE" would not check to see if the executing
user had permission to perform a "SELECT" on the index performing the
conflicting check. Additionally, in a table with row-level security enabled,
the "INSERT ... ON CONFLICT DO UPDATE" would not check the SELECT policies for
that table before performing the update (CVE-2017-15099).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12172
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15098
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15099
https://www.postgresql.org/docs/9.3/static/release-9-3-20.html
https://www.postgresql.org/docs/9.4/static/release-9-4-15.html
https://www.postgresql.org/docs/9.6/static/release-9-6-6.html
https://www.postgresql.org/about/news/1801/
========================

Updated packages in core/updates_testing:
========================
postgresql9.3-9.3.20-1.mga5
libpq9.3_5.6-9.3.20-1.mga5
libecpg9.3_6-9.3.20-1.mga5
postgresql9.3-server-9.3.20-1.mga5
postgresql9.3-docs-9.3.20-1.mga5
postgresql9.3-contrib-9.3.20-1.mga5
postgresql9.3-devel-9.3.20-1.mga5
postgresql9.3-pl-9.3.20-1.mga5
postgresql9.3-plpython-9.3.20-1.mga5
postgresql9.3-plperl-9.3.20-1.mga5
postgresql9.3-pltcl-9.3.20-1.mga5
postgresql9.3-plpgsql-9.3.20-1.mga5
postgresql9.4-9.4.15-1.mga5
libpq5-9.4.15-1.mga5
libecpg9.4_6-9.4.15-1.mga5
postgresql9.4-server-9.4.15-1.mga5
postgresql9.4-docs-9.4.15-1.mga5
postgresql9.4-contrib-9.4.15-1.mga5
postgresql9.4-devel-9.4.15-1.mga5
postgresql9.4-pl-9.4.15-1.mga5
postgresql9.4-plpython-9.4.15-1.mga5
postgresql9.4-plperl-9.4.15-1.mga5
postgresql9.4-pltcl-9.4.15-1.mga5
postgresql9.4-plpgsql-9.4.15-1.mga5
postgresql9.4-9.4.15-1.mga6
libpq5.7-9.4.15-1.mga6
libecpg9.4_6-9.4.15-1.mga6
postgresql9.4-server-9.4.15-1.mga6
postgresql9.4-docs-9.4.15-1.mga6
postgresql9.4-contrib-9.4.15-1.mga6
postgresql9.4-devel-9.4.15-1.mga6
postgresql9.4-pl-9.4.15-1.mga6
postgresql9.4-plpython-9.4.15-1.mga6
postgresql9.4-plperl-9.4.15-1.mga6
postgresql9.4-pltcl-9.4.15-1.mga6
postgresql9.4-plpgsql-9.4.15-1.mga6
postgresql9.6-9.6.6-1.mga6
libpq5-9.6.6-1.mga6
libecpg9.6_6-9.6.6-1.mga6
postgresql9.6-server-9.6.6-1.mga6
postgresql9.6-docs-9.6.6-1.mga6
postgresql9.6-contrib-9.6.6-1.mga6
postgresql9.6-devel-9.6.6-1.mga6
postgresql9.6-pl-9.6.6-1.mga6
postgresql9.6-plpython-9.6.6-1.mga6
postgresql9.6-plperl-9.6.6-1.mga6
postgresql9.6-pltcl-9.6.6-1.mga6
postgresql9.6-plpgsql-9.6.6-1.mga6

from SRPMS:
postgresql9.3-9.3.20-1.mga5.src.rpm
postgresql9.4-9.4.15-1.mga5.src.rpm
postgresql9.4-9.4.15-1.mga6.src.rpm
postgresql9.6-9.6.6-1.mga6.src.rpm
Comment 1 David Walser 2017-11-10 01:59:12 CET
They don't build in Cauldron due to breakage in the osx command (opensp package).  CC'ing Guillaume who changed opensp in Cauldron.

CC: (none) => cjw, guillomovitch
Whiteboard: (none) => MGA5TOO
Keywords: (none) => has_procedure

Comment 2 David Walser 2017-11-10 14:39:44 CET
Debian has issued advisories for this on November 9:
https://www.debian.org/security/2017/dsa-4028
https://www.debian.org/security/2017/dsa-4027

They also had this one.  I don't think we have these commands packaged, but hopefully Christiaan can confirm it's not relevant for us:
https://www.debian.org/security/2017/dsa-4029
Comment 3 David Walser 2017-11-10 14:52:29 CET
(In reply to David Walser from comment #2)
> They also had this one.  I don't think we have these commands packaged, but
> hopefully Christiaan can confirm it's not relevant for us:
> https://www.debian.org/security/2017/dsa-4029

Also seen here with another CVE:
https://usn.ubuntu.com/usn/usn-3476-1/

but it does appear to be a Debian-specific thing.
Comment 4 Herman Viaene 2017-11-11 10:39:22 CET
MGA5-32 on Asus A6000VM Xfce
Installed 9.4.15-1 over existing 9.4.13-1
Existing test database intact and working. Could create new database and new table in it.

CC: (none) => herman.viaene
Whiteboard: MGA5TOO => MGA5TOO MGA5-32-OK

Comment 5 Guillaume Rousse 2017-11-11 14:25:13 CET
The docbook nightmare never ends... I just fixed the docbook-dtds package, you should be able to rebuild postgresql in cauldron now.
Lewis Smith 2017-11-19 11:42:02 CET

Keywords: (none) => advisory

Comment 6 Herman Viaene 2017-11-22 16:21:50 CET
MGA5-64 on Lenovo B50 KDE
No installation issues
Using phppgadmin first threw "Login disallowed for security reasons."
Setting $conf['extra_login_security'] = false; in /etc/phppgadmin/conf.inc.php solved this. Postgres was installed before, so I could use the existing database.
Then I could create a table in the public schema, create a new schema anda table in that one. All seems OK.

Whiteboard: MGA5TOO MGA5-32-OK => MGA5TOO MGA5-32-OK MGA5-64-OK

Comment 7 Lewis Smith 2017-11-27 21:18:59 CET
Testing M6/64 AFTER update for:
 postgresql9.6-plpgsql-9.6.6-1.mga6
 postgresql9.6-9.6.6-1.mga6
 postgresql9.6-server-9.6.6-1.mga6
 lib64pq5-9.6.6-1.mga6

To drive this, I used: pgAdmin3, MediaWiki, Bugzilla
 pgAdmin3:
I could create a database, add tables, alter them, delete them; same for columns. Unable to add any data because I could *not* find how to define table primary keys with it - a prerequisite.
 MediaWiki, Bugzilla:
Added and edited entitites; all seemed OK.

I am OKing & validating this because Herman covered M5 and Postgres 9.4, here M6 and Postgres 9.6.
If anyone wants also M5/Postgres 9.3 and M6/Postgres 9.4, please shout & unvalidate.

CC: (none) => lewyssmith, sysadmin-bugs
Whiteboard: MGA5TOO MGA5-32-OK MGA5-64-OK => MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-64-OK
Keywords: (none) => validated_update

Comment 8 Mageia Robot 2017-11-29 19:53:31 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2017-0428.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.