Upstream has issued an advisory on May 11: https://www.postgresql.org/about/news/1746/ The issues are fixed in 9.3.17, 9.4.12, and 9.6.3. Mageia 5 is also affected. Debian has issued an advisory for this on May 12: https://www.debian.org/security/2017/dsa-3851
Whiteboard: (none) => MGA5TOO
Assigning to cjw, the postgresql9.4 maintainer, because I saw he was active today. I guess this report needs to be cloned for postgresql9.3 (no registered maintainer) and postgresql9.6 (joequant)?
Assignee: bugsquad => cjwCC: (none) => joequant, marja11, pkg-bugs
(In reply to Marja van Waes from comment #1) > I guess this report needs to be cloned for postgresql9.3 (no registered > maintainer) and postgresql9.6 (joequant)? Nope.
Package : postgresql-9.4 CVE ID : CVE-2017-7484 CVE-2017-7485 CVE-2017-7486 Several vulnerabilities have been found in the PostgreSQL database system: CVE-2017-7484 Robert Haas discovered that some selectivity estimators did not validate user privileges which could result in information disclosure. CVE-2017-7485 Daniel Gustafsson discovered that the PGREQUIRESSL environment variable did no longer enforce a TLS connection. CVE-2017-7486 Andrew Wheelwright discovered that user mappings were insufficiently restricted.
CC: (none) => zombie_ryushu
Fixed in cauldron
Whiteboard: MGA5TOO => (none)CC: (none) => mageiaVersion: Cauldron => 5
Updated packages uploaded for Mageia 5. Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=18103#c6 Advisory: ======================== Updated postgresql packages fix security vulnerabilities: Robert Haas discovered that some selectivity estimators did not validate user privileges which could result in information disclosure (CVE-2017-7484). Daniel Gustafsson discovered that the PGREQUIRESSL environment variable did no longer enforce a TLS connection (CVE-2017-7485). Andrew Wheelwright discovered that user mappings were insufficiently restricted (CVE-2017-7486). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7484 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7485 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7486 http://www.postgresql.org/docs/current/static/release-9-3-17.html http://www.postgresql.org/docs/current/static/release-9-4-12.html https://www.postgresql.org/about/news/1746/ ======================== Updated packages in core/updates_testing: ======================== postgresql9.3-9.3.17-1.mga5 libpq9.3_5.6-9.3.17-1.mga5 libecpg9.3_6-9.3.17-1.mga5 postgresql9.3-server-9.3.17-1.mga5 postgresql9.3-docs-9.3.17-1.mga5 postgresql9.3-contrib-9.3.17-1.mga5 postgresql9.3-devel-9.3.17-1.mga5 postgresql9.3-pl-9.3.17-1.mga5 postgresql9.3-plpython-9.3.17-1.mga5 postgresql9.3-plperl-9.3.17-1.mga5 postgresql9.3-pltcl-9.3.17-1.mga5 postgresql9.3-plpgsql-9.3.17-1.mga5 postgresql9.4-9.4.12-1.mga5 libpq5-9.4.12-1.mga5 libecpg9.4_6-9.4.12-1.mga5 postgresql9.4-server-9.4.12-1.mga5 postgresql9.4-docs-9.4.12-1.mga5 postgresql9.4-contrib-9.4.12-1.mga5 postgresql9.4-devel-9.4.12-1.mga5 postgresql9.4-pl-9.4.12-1.mga5 postgresql9.4-plpython-9.4.12-1.mga5 postgresql9.4-plperl-9.4.12-1.mga5 postgresql9.4-pltcl-9.4.12-1.mga5 postgresql9.4-plpgsql-9.4.12-1.mga5 from SRPMS: postgresql9.3-9.3.17-1.mga5.src.rpm postgresql9.4-9.4.12-1.mga5.src.rpm
Assignee: cjw => qa-bugsWhiteboard: (none) => has_procedureCC: (none) => cjw
Note that there is a postgresql9.4-9.4.12-1.1.mga6 in Mageia 6 updates_testing that needs to go out the same time as this to keep the upgrade path from mga5 -> mga6 working...
CC: (none) => tmb
Why?
Because anyone who installed postgresql9.4-9.4.12-1.mga5, and there were some who did, could, during Mga5 to Mga6 upgrades hit: Installation failed file libpq.so.5 from install of lib64pq5-9.6.3-1.mga6 conflicts with installed lib64pq5-9.4.12-1.mga5 postgresql9.4-9.4.12-1.1.mga6 in Mga6 updates_testing fixes this but when it is moved to Mga6 /updates/ then, because it is a security update postgresql9.4-9.4.12-1.mga5 also needs to be moved to Mga5 /updates/. Both need to stay in sync until Mga5 reaches EOL later this year.
CC: (none) => cae
(In reply to Charles Edwards from comment #8) > postgresql9.4-9.4.12-1.1.mga6 in Mga6 updates_testing fixes this but when it > is moved to Mga6 /updates/ then, because it is a security update > postgresql9.4-9.4.12-1.mga5 also needs to be moved to Mga5 /updates/. Actually no, the Mageia update could be validated and pushed already, it just updates the Obsoletes version to match %{version}. But indeed the most logical would be to push the Mageia 6 fix together with the Mageia 5 security update that requires this fix, I'll adapt the advisory accordingly. Advisory: ======================== Updated postgresql packages fix security vulnerabilities: Robert Haas discovered that some selectivity estimators did not validate user privileges which could result in information disclosure (CVE-2017-7484). Daniel Gustafsson discovered that the PGREQUIRESSL environment variable did no longer enforce a TLS connection (CVE-2017-7485). Andrew Wheelwright discovered that user mappings were insufficiently restricted (CVE-2017-7486). The Mageia 6 postgresql9.4 update is a packaging bugfix to ease the upgrade from Mageia 5 to Mageia 6. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7484 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7485 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7486 http://www.postgresql.org/docs/current/static/release-9-3-17.html http://www.postgresql.org/docs/current/static/release-9-4-12.html https://www.postgresql.org/about/news/1746/ ======================== SRPMs: 5: - postgresql9.3-9.3.17-1.mga5.src.rpm - postgresql9.4-9.4.12-1.mga5.src.rpm 6: - postgresql9.4-9.4.12-1.1.mga6.src.rpm
Whiteboard: has_procedure => has_procedure advisory
$ uname -a Linux localhost 4.4.74-desktop-1.mga5 #1 SMP Mon Jun 26 08:33:18 UTC 2017 i686 i686 i686 GNU/Linux The following 17 packages are going to be installed: - glibc-devel-2.20-25.mga5.i586 - kernel-userspace-headers-4.4.79-1.mga5.i586 - libecpg9.3_6-9.3.17-1.mga5.i586 - libopenssl-devel-1.0.2k-1.mga5.i586 - libossp_uuid16-1.6.2-12.mga5.i586 - libpq9.3_5.6-9.3.17-1.mga5.i586 - libzlib-devel-1.2.8-7.1.mga5.i586 - postgresql9.3-9.3.17-1.mga5.i586 - postgresql9.3-contrib-9.3.17-1.mga5.i586 - postgresql9.3-devel-9.3.17-1.mga5.i586 - postgresql9.3-docs-9.3.17-1.mga5.noarch - postgresql9.3-pl-9.3.17-1.mga5.i586 - postgresql9.3-plperl-9.3.17-1.mga5.i586 - postgresql9.3-plpgsql-9.3.17-1.mga5.i586 - postgresql9.3-plpython-9.3.17-1.mga5.i586 - postgresql9.3-pltcl-9.3.17-1.mga5.i586 - postgresql9.3-server-9.3.17-1.mga5.i586 57MB of additional disk space will be used. 13MB of packages will be retrieved. Is it ok to continue? Rebooted the machine and ran a process check. $ ps -ef | grep post postgres 2171 1 0 12:01 ? 00:00:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432 postgres 2173 2171 0 12:01 ? 00:00:00 postgres: checkpointer process postgres 2174 2171 0 12:01 ? 00:00:00 postgres: writer process postgres 2175 2171 0 12:01 ? 00:00:00 postgres: wal writer process postgres 2176 2171 0 12:01 ? 00:00:00 postgres: autovacuum launcher process postgres 2177 2171 0 12:01 ? 00:00:00 postgres: stats collector process brian 2872 2802 0 12:02 pts/0 00:00:00 grep --color post $ Server is up Next my user-id will not have a role in postgres. You'll notice that the services are running by postgres, but there isn't a password set for it. So to set up a role, you must first become root. (I am pulling this info from: https://www.liquidweb.com/kb/what-is-the-default-password-for-postgresql/ $ su <root password> Then you can su to postgres ID # su - postgres gpg-agent[4346]: directory `/var/lib/pgsql/.gnupg' created gpg-agent[4346]: directory `/var/lib/pgsql/.gnupg/private-keys-v1.d' created gpg-agent[4347]: gpg-agent (GnuPG) 2.0.27 started Then you can go into postgressql client $ psql psql (9.3.17) Type "help" for help. postgres=# to log out. # \q Now create the database mydb # su postgres $ createdb mydb mydb=> create table brian (name varchar(20)); CREATE TABLE mydb=> insert into brian values ('briansname'); INSERT 0 1 mydb=> insert into brian values ('postgressql is awesome'); ERROR: value too long for type character varying(20) mydb=> insert into brian values ('psql is awesome'); INSERT 0 1 mydb=> select * from brian; name ----------------- briansname psql is awesome (2 rows) mydb=> drop table brian mydb-> ; DROP TABLE mydb=> \q Works as designed. **Please note you may need to add your ID on your box to the postgres group.
CC: (none) => brtians1Whiteboard: has_procedure advisory => has_procedure advisory mga5-32-ok
The following 17 packages are going to be installed: - glibc-devel-2.20-25.mga5.x86_64 - kernel-userspace-headers-4.4.79-1.mga5.x86_64 - lib64ecpg9.3_6-9.3.17-1.mga5.x86_64 - lib64openssl-devel-1.0.2k-1.mga5.x86_64 - lib64ossp_uuid16-1.6.2-12.mga5.x86_64 - lib64pq9.3_5.6-9.3.17-1.mga5.x86_64 - lib64zlib-devel-1.2.8-7.1.mga5.x86_64 - postgresql9.3-9.3.17-1.mga5.x86_64 - postgresql9.3-contrib-9.3.17-1.mga5.x86_64 - postgresql9.3-devel-9.3.17-1.mga5.x86_64 - postgresql9.3-docs-9.3.17-1.mga5.noarch - postgresql9.3-pl-9.3.17-1.mga5.x86_64 - postgresql9.3-plperl-9.3.17-1.mga5.x86_64 - postgresql9.3-plpgsql-9.3.17-1.mga5.x86_64 - postgresql9.3-plpython-9.3.17-1.mga5.x86_64 - postgresql9.3-pltcl-9.3.17-1.mga5.x86_64 - postgresql9.3-server-9.3.17-1.mga5.x86_64 58MB of additional disk space will be used. 13MB of packages will be retrieved. Is it ok to continue? Restarted machine [brian@localhost ~]$ uname -a Linux localhost 4.4.74-desktop-1.mga5 #1 SMP Mon Jun 26 07:50:58 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [brian@localhost ~]$ ps -ef | grep post postgres 2065 1 0 13:19 ? 00:00:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432 postgres 2067 2065 0 13:19 ? 00:00:00 postgres: checkpointer process postgres 2068 2065 0 13:19 ? 00:00:00 postgres: writer process postgres 2069 2065 0 13:19 ? 00:00:00 postgres: wal writer process postgres 2070 2065 0 13:19 ? 00:00:00 postgres: autovacuum launcher process postgres 2071 2065 0 13:19 ? 00:00:00 postgres: stats collector process brian 2685 2609 0 13:20 pts/1 00:00:00 grep --color post [brian@localhost ~]$ [postgres@localhost brian]$ createuser brian [postgres@localhost brian]$ createdb mydb postgres@localhost brian]$ psql psql (9.3.17) Type "help" for help. postgres=# I quit the psql tool and exit out of postgres and root back to my ID. Then log into psql from my ID [brian@localhost ~]$ psql mydb psql (9.3.17) Type "help" for help. mydb=> it works now [brian@localhost ~]$ psql mydb psql (9.3.17) Type "help" for help. mydb=> create table brian (name varchar(20)); CREATE TABLE mydb=> insert into brian values ('briansname-64bit'); INSERT 0 1 mydb=> insert into brian values ('I'); INSERT 0 1 mydb=> insert into brian values ('love'); INSERT 0 1 mydb=> insert into brian values ('command'); INSERT 0 1 mydb=> insert into brian values ('lines'); INSERT 0 1 mydb=> select * from brian; name ------------------ briansname-64bit I love command lines (5 rows) mydb=> update brian mydb-> set names = 'we' mydb-> where names = 'I'; ERROR: column "names" does not exist LINE 3: where names = 'I'; ^ mydb=> update brian set name = 'we' where name = 'I'; UPDATE 1 mydb=> select * from brian; name ------------------ briansname-64bit love command lines we (5 rows) works as designed.
Whiteboard: has_procedure advisory mga5-32-ok => has_procedure advisory mga5-32-ok mga5-64-ok
Needs 9.4 test on mga5 to validate Brian please
Version: 5 => 6Whiteboard: has_procedure advisory mga5-32-ok mga5-64-ok => MGA5TOO has_procedure advisory mga5-32-ok mga5-64-ok
And mga6 too, sorry.
This can be validated. This bug was only for Mageia 5. The Mageia 6 update is a bugfix update that's just for fixing an upgrade issue. It should have its own bug.
Version: 6 => 5Whiteboard: MGA5TOO has_procedure advisory mga5-32-ok mga5-64-ok => has_procedure advisory mga5-32-ok mga5-64-ok
No, it can't be validated (or at least it can't be pushed). If the Mageia 6 update is not pushed before, or at the same time, then the upgrade conflicts will occur. But if you really want it to go in another bug, fair enough, just don't validate this one until the new one is validated.
It can be validated. Just make another bug for Mageia 6 blocking this one.
Depends on: (none) => 21232
(In reply to David Walser from comment #16) > It can be validated. Just make another bug for Mageia 6 blocking this one. You mentioned a couple days ago that the "Blocks" mechanism no longer seems to prevent pushing updates, so I prefer not taking the chance to introduce a regression if we can avoid it. Advisory fixed to remove reference to Mageia 6 SRPM and update reason.
Ahh thanks for the reminder. Yeah the updates pushing script needs to be fixed.
CC: (none) => sysadmin-bugs
Bug 21232 is validated, so this one can be too.
Keywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0230.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Hi - Do I need to continue with mga5 postgressql 9.4 testing?
(In reply to David Walser from comment #18) > Ahh thanks for the reminder. Yeah the updates pushing script needs to be > fixed. AFAIK it's not broken... if some update has gone out regardless of blocker status, it's ususlly the one running the script pressing "Y" intstead of "Enter" when the question pops up, thereby overriding the blocker status