Bug 20842 - postgresql new security issues CVE-2017-748[4-6]
Summary: postgresql new security issues CVE-2017-748[4-6]
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: has_procedure advisory mga5-32-ok mga...
Keywords: validated_update
Depends on: 21232
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-13 19:06 CEST by David Walser
Modified: 2017-07-30 19:42 CEST (History)
10 users (show)

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


Attachments

Description David Walser 2017-05-13 19:06:02 CEST
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
David Walser 2017-05-13 19:06:16 CEST

Whiteboard: (none) => MGA5TOO

Comment 1 Marja Van Waes 2017-05-13 20:06:13 CEST
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 => cjw
CC: (none) => joequant, marja11, pkg-bugs

Comment 2 David Walser 2017-05-13 20:43:31 CEST
(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.
Comment 3 Zombie Ryushu 2017-05-14 14:59:56 CEST
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

Comment 4 Nicolas Lécureuil 2017-05-15 01:25:15 CEST
Fixed in cauldron

Whiteboard: MGA5TOO => (none)
CC: (none) => mageia
Version: Cauldron => 5

Comment 5 David Walser 2017-07-09 01:38:25 CEST
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-bugs
Whiteboard: (none) => has_procedure
CC: (none) => cjw

Comment 6 Thomas Backlund 2017-07-17 22:15:45 CEST
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

Comment 7 David Walser 2017-07-18 01:49:22 CEST
Why?
Comment 8 Charles Edwards 2017-07-18 02:39:06 CEST
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

Comment 9 Rémi Verschelde 2017-07-18 07:44:29 CEST
(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
Rémi Verschelde 2017-07-18 07:46:55 CEST

Whiteboard: has_procedure => has_procedure advisory

Comment 10 Brian Rockwell 2017-07-28 19:57:14 CEST
$ 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) => brtians1
Whiteboard: has_procedure advisory => has_procedure advisory mga5-32-ok

Comment 11 Brian Rockwell 2017-07-28 22:17:03 CEST
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

Comment 12 claire robinson 2017-07-30 14:00:45 CEST
Needs 9.4 test on mga5 to validate Brian please
claire robinson 2017-07-30 14:03:42 CEST

Version: 5 => 6
Whiteboard: has_procedure advisory mga5-32-ok mga5-64-ok => MGA5TOO has_procedure advisory mga5-32-ok mga5-64-ok

Comment 13 claire robinson 2017-07-30 14:04:36 CEST
And mga6 too, sorry.
Comment 14 David Walser 2017-07-30 16:20:45 CEST
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 => 5
Whiteboard: MGA5TOO has_procedure advisory mga5-32-ok mga5-64-ok => has_procedure advisory mga5-32-ok mga5-64-ok

Comment 15 Rémi Verschelde 2017-07-30 16:24:42 CEST
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.
Comment 16 David Walser 2017-07-30 16:29:34 CEST
It can be validated.  Just make another bug for Mageia 6 blocking this one.
Rémi Verschelde 2017-07-30 16:29:49 CEST

Depends on: (none) => 21232

Comment 17 Rémi Verschelde 2017-07-30 16:31:37 CEST
(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.
Comment 18 David Walser 2017-07-30 16:32:42 CEST
Ahh thanks for the reminder.  Yeah the updates pushing script needs to be fixed.

CC: (none) => sysadmin-bugs

Comment 19 Rémi Verschelde 2017-07-30 16:34:33 CEST
Bug 21232 is validated, so this one can be too.

Keywords: (none) => validated_update

Comment 20 Mageia Robot 2017-07-30 17:59:40 CEST
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0230.html

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

Comment 21 Brian Rockwell 2017-07-30 18:51:56 CEST
Hi - Do I need to continue with mga5 postgressql 9.4 testing?
Comment 22 Thomas Backlund 2017-07-30 19:42:47 CEST
(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

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