Upstream has issued an advisory on February 20: http://article.gmane.org/gmane.comp.db.postgresql.announce/2371 Debian has issued advisories for this on February 20: http://www.debian.org/security/2014/dsa-2864 http://www.debian.org/security/2014/dsa-2865 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Funda updated these in Cauldron.
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Blocks: (none) => 12782
Mandriva has issued an advisory for this: http://www.mandriva.com/en/support/security/advisories/mbs1/MDVSA-2014:047/
CC: (none) => doktor5000Blocks: (none) => 13241
WHOA - altogether 8 CVEs for 4 postgresql version in parallel - did I really volunteer to help with this ... :/ FWIW, here's the CVE list including affected versions & descriptions: CVE-2014-0060 PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 does not properly enforce the ADMIN OPTION restriction, which allows remote authenticated members of a role to add or remove arbitrary users to that role by calling the SET ROLE command before the associated GRANT command. CVE-2014-0061 The validator functions for the procedural languages (PLs) in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 allow remote authenticated users to gain privileges via a function that is (1) defined in another language or (2) not allowed to be directly called by the user due to permissions. CVE-2014-0062 Race condition in the (1) CREATE INDEX and (2) unspecified ALTER TABLE commands in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 allows remote authenticated users to create an unauthorized index or read portions of unauthorized tables by creating or deleting a table with the same name during the timing window. CVE-2014-0063 Multiple stack-based buffer overflows in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 allow remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via vectors related to an incorrect MAXDATELEN constant and datetime values involving (1) intervals, (2) timestamps, or (3) timezones, a different vulnerability than CVE-2014-0065. CVE-2014-0064 Multiple integer overflows in the path_in and other unspecified functions in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 allow remote authenticated users to have unspecified impact and attack vectors, which trigger a buffer overflow. NOTE: this identifier has been SPLIT due to different affected versions; use CVE-2014-2669 for the hstore vector. CVE-2014-0065 Multiple buffer overflows in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 allow remote authenticated users to have unspecified impact and attack vectors, a different vulnerability than CVE-2014-0063. CVE-2014-0066 The chkpass extension in PostgreSQL before 8.4.20, 9.0.x before 9.0.16, 9.1.x before 9.1.12, 9.2.x before 9.2.7, and 9.3.x before 9.3.3 does not properly check the return value of the crypt library function, which allows remote authenticated users to cause a denial of service (NULL pointer dereference and crash) via unspecified vectors. CVE-2014-0067 The "make check" command for the test suites in PostgreSQL 9.3.3 and earlier does not properly invoke initdb to specify the authentication requirements for a database cluster to be used for the tests, which allows local users to gain privileges by leveraging access to this cluster. Currently working from mga4/9.3 backwards, updating to fixed minor versions: 9.3.3 9.2.7 9.1.12 9.0.16
Status: NEW => ASSIGNEDCC: (none) => fundawangAssignee: fundawang => doktor5000
The following updates candidates have been submitted for 4 core/updates_testing : postgresql9.0-9.0.17-2.mga4 postgresql9.1-9.1.13-2.mga4 postgresql9.2-9.2.8-2.mga4 postgresql9.3-9.3.4-1.mga4 Just noticed that the fix for https://bugs.mageia.org/show_bug.cgi?id=13241 still needs to be added for 9.2-9.0 -.- Will submit those tomorrow again and then continue with mga3.
Seems only postgresql9.3-server requires the fix for postgresql.tmpfiles.d so those updates are ready for testing. For the advisory or POC, cannot help much further than https://bugs.mageia.org/show_bug.cgi?id=12841#c3 This should be the list of packages: x86_64 postgresql9.0-devel-9.0.17-2.mga4.x86_64.rpm postgresql9.0-debuginfo-9.0.17-2.mga4.x86_64.rpm postgresql9.0-server-9.0.17-2.mga4.x86_64.rpm lib64pq9.0_5.3-9.0.17-2.mga4.x86_64.rpm postgresql9.0-plpgsql-9.0.17-2.mga4.x86_64.rpm lib64ecpg9.0_6-9.0.17-2.mga4.x86_64.rpm postgresql9.0-pltcl-9.0.17-2.mga4.x86_64.rpm postgresql9.0-plperl-9.0.17-2.mga4.x86_64.rpm postgresql9.0-9.0.17-2.mga4.x86_64.rpm postgresql9.0-contrib-9.0.17-2.mga4.x86_64.rpm postgresql9.0-pl-9.0.17-2.mga4.x86_64.rpm postgresql9.0-plpython-9.0.17-2.mga4.x86_64.rpm postgresql9.0-docs-9.0.17-2.mga4.noarch.rpm postgresql9.1-debuginfo-9.1.13-2.mga4.x86_64.rpm postgresql9.1-pltcl-9.1.13-2.mga4.x86_64.rpm lib64pq9.1_5.4-9.1.13-2.mga4.x86_64.rpm postgresql9.1-server-9.1.13-2.mga4.x86_64.rpm postgresql9.1-contrib-9.1.13-2.mga4.x86_64.rpm postgresql9.1-9.1.13-2.mga4.x86_64.rpm postgresql9.1-plperl-9.1.13-2.mga4.x86_64.rpm postgresql9.1-plpgsql-9.1.13-2.mga4.x86_64.rpm postgresql9.1-plpython-9.1.13-2.mga4.x86_64.rpm lib64ecpg9.1_6-9.1.13-2.mga4.x86_64.rpm postgresql9.1-devel-9.1.13-2.mga4.x86_64.rpm postgresql9.1-pl-9.1.13-2.mga4.x86_64.rpm postgresql9.1-docs-9.1.13-2.mga4.noarch.rpm lib64pq9.2_5.5-9.2.8-2.mga4.x86_64.rpm postgresql9.2-contrib-9.2.8-2.mga4.x86_64.rpm postgresql9.2-9.2.8-2.mga4.x86_64.rpm postgresql9.2-server-9.2.8-2.mga4.x86_64.rpm postgresql9.2-devel-9.2.8-2.mga4.x86_64.rpm postgresql9.2-plperl-9.2.8-2.mga4.x86_64.rpm postgresql9.2-plpython-9.2.8-2.mga4.x86_64.rpm postgresql9.2-debuginfo-9.2.8-2.mga4.x86_64.rpm postgresql9.2-pltcl-9.2.8-2.mga4.x86_64.rpm postgresql9.2-plpgsql-9.2.8-2.mga4.x86_64.rpm postgresql9.2-pl-9.2.8-2.mga4.x86_64.rpm lib64ecpg9.2_6-9.2.8-2.mga4.x86_64.rpm postgresql9.2-docs-9.2.8-2.mga4.noarch.rpm postgresql9.3-pltcl-9.3.4-1.mga4.x86_64.rpm lib64pq9.3_5-9.3.4-1.mga4.x86_64.rpm postgresql9.3-debuginfo-9.3.4-1.mga4.x86_64.rpm postgresql9.3-server-9.3.4-1.mga4.x86_64.rpm postgresql9.3-pl-9.3.4-1.mga4.x86_64.rpm postgresql9.3-plpython-9.3.4-1.mga4.x86_64.rpm lib64ecpg9.3_6-9.3.4-1.mga4.x86_64.rpm postgresql9.3-plpgsql-9.3.4-1.mga4.x86_64.rpm postgresql9.3-plperl-9.3.4-1.mga4.x86_64.rpm postgresql9.3-9.3.4-1.mga4.x86_64.rpm postgresql9.3-contrib-9.3.4-1.mga4.x86_64.rpm postgresql9.3-devel-9.3.4-1.mga4.x86_64.rpm postgresql9.3-docs-9.3.4-1.mga4.noarch.rpm i586 postgresql9.0-devel-9.0.17-2.mga4.i586.rpm postgresql9.0-debuginfo-9.0.17-2.mga4.i586.rpm postgresql9.0-server-9.0.17-2.mga4.i586.rpm lib64pq9.0_5.3-9.0.17-2.mga4.i586.rpm postgresql9.0-plpgsql-9.0.17-2.mga4.i586.rpm lib64ecpg9.0_6-9.0.17-2.mga4.i586.rpm postgresql9.0-pltcl-9.0.17-2.mga4.i586.rpm postgresql9.0-plperl-9.0.17-2.mga4.i586.rpm postgresql9.0-9.0.17-2.mga4.i586.rpm postgresql9.0-contrib-9.0.17-2.mga4.i586.rpm postgresql9.0-pl-9.0.17-2.mga4.i586.rpm postgresql9.0-plpython-9.0.17-2.mga4.i586.rpm postgresql9.0-docs-9.0.17-2.mga4.noarch.rpm postgresql9.1-debuginfo-9.1.13-2.mga4.i586.rpm postgresql9.1-pltcl-9.1.13-2.mga4.i586.rpm lib64pq9.1_5.4-9.1.13-2.mga4.i586.rpm postgresql9.1-server-9.1.13-2.mga4.i586.rpm postgresql9.1-contrib-9.1.13-2.mga4.i586.rpm postgresql9.1-9.1.13-2.mga4.i586.rpm postgresql9.1-plperl-9.1.13-2.mga4.i586.rpm postgresql9.1-plpgsql-9.1.13-2.mga4.i586.rpm postgresql9.1-plpython-9.1.13-2.mga4.i586.rpm lib64ecpg9.1_6-9.1.13-2.mga4.i586.rpm postgresql9.1-devel-9.1.13-2.mga4.i586.rpm postgresql9.1-pl-9.1.13-2.mga4.i586.rpm postgresql9.1-docs-9.1.13-2.mga4.noarch.rpm lib64pq9.2_5.5-9.2.8-2.mga4.i586.rpm postgresql9.2-contrib-9.2.8-2.mga4.i586.rpm postgresql9.2-9.2.8-2.mga4.i586.rpm postgresql9.2-server-9.2.8-2.mga4.i586.rpm postgresql9.2-devel-9.2.8-2.mga4.i586.rpm postgresql9.2-plperl-9.2.8-2.mga4.i586.rpm postgresql9.2-plpython-9.2.8-2.mga4.i586.rpm postgresql9.2-debuginfo-9.2.8-2.mga4.i586.rpm postgresql9.2-pltcl-9.2.8-2.mga4.i586.rpm postgresql9.2-plpgsql-9.2.8-2.mga4.i586.rpm postgresql9.2-pl-9.2.8-2.mga4.i586.rpm lib64ecpg9.2_6-9.2.8-2.mga4.i586.rpm postgresql9.2-docs-9.2.8-2.mga4.noarch.rpm postgresql9.3-pltcl-9.3.4-1.mga4.i586.rpm lib64pq9.3_5-9.3.4-1.mga4.i586.rpm postgresql9.3-debuginfo-9.3.4-1.mga4.i586.rpm postgresql9.3-server-9.3.4-1.mga4.i586.rpm postgresql9.3-pl-9.3.4-1.mga4.i586.rpm postgresql9.3-plpython-9.3.4-1.mga4.i586.rpm lib64ecpg9.3_6-9.3.4-1.mga4.i586.rpm postgresql9.3-plpgsql-9.3.4-1.mga4.i586.rpm postgresql9.3-plperl-9.3.4-1.mga4.i586.rpm postgresql9.3-9.3.4-1.mga4.i586.rpm postgresql9.3-contrib-9.3.4-1.mga4.i586.rpm postgresql9.3-devel-9.3.4-1.mga4.i586.rpm postgresql9.3-docs-9.3.4-1.mga4.noarch.rpm SRPMs postgresql9.0-9.0.17-2.mga4.src.rpm postgresql9.1-9.1.13-2.mga4.src.rpm postgresql9.2-9.2.8-2.mga4.src.rpm postgresql9.3-9.3.4-1.mga4.src.rpm
Hardware: i586 => AllAssignee: doktor5000 => qa-bugs
@QA: please also test postgresql9.3-server for https://bugs.mageia.org/show_bug.cgi?id=13241 If reproducer is needed, I can add it there for easier testing.
General testing procedure here: https://bugs.mageia.org/show_bug.cgi?id=8997#c1 When testing postgresql9.3 please also test the specific bug mentioned here: https://bugs.mageia.org/show_bug.cgi?id=13241#c9 ----- To reproduce and simulate installation on freshly installed system (WARNING: this will wipe your postgres databases!) urpme $(rpm -qa | grep ^postgresql9.3) 1>/dev/null; rm -rf /var/lib/pgsql ; rm -rf /var/run/postgresql #verify socket directory does not exist: ls -ald /var/run/postgresql #install and start postgres server, then check status urpmi postgresql9.3-server --auto && systemctl start postgresql && sleep 3; systemctl status postgresql #see the failure Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details. #verify socket directory has not been created: ls -ald /var/run/postgresql ====================================================================== #rinse and repeat with update candidate, socket directory should exist # ls -ald /var/run/postgresql drwxr-xr-x 2 postgres postgres 40 Mai 5 21:05 /var/run/postgresql/ -----
Whiteboard: MGA3TOO => MGA3TOO has_procedure
Testing complete mga4 64 Confirmed 9.3 is fixed (bug 13241) Before ------ # systemctl start postgresql.service Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details. # systemctl -l status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: failed (Result: exit-code) since Tue 2014-05-06 11:38:37 BST; 6s ago pg_ctl[23520]: FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": No such file or directory pg_ctl[23520]: pg_ctl: could not start server ...etc After ----- # systemctl start postgresql.service # systemctl -l status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: active (running) since Tue 2014-05-06 11:39:39 BST; 3s ago ...etc Loaded sql from the world.sql file using the postgresql webmin module (https://localhost:10000 after starting webmin service) and viewed the data. Testing the rest.. eg. # urpme -a postgresql9.3 lib64pq9.3 # rm -rf /var/lib/pgsql # urpmi postgresql9.2 postgresql9.2-server # service postgresql start Refresh modules in webmin by clicking the link on the left and repeat the world.sql test - Create a new database, click on it then select Execute SQL and select the Run SQL from File tab, find world.sql and load it then view the data.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga4-64-ok
Testing complete mga4 32 Florian do you want us to validate this now for mga4 and you create a separate bug for mga3 or should we wait now until the mga3 updates are ready and push both together? We'll need an advisory though before we can do either, depending how you want to handle it.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga4-32-ok mga4-64-ok
(In reply to claire robinson from comment #9) > Testing complete mga4 32 > > Florian do you want us to validate this now for mga4 and you create a > separate bug for mga3 or should we wait now until the mga3 updates are ready > and push both together? Whatever is less work. > > We'll need an advisory though before we can do either, depending how you > want to handle it. Doesn't https://bugs.mageia.org/show_bug.cgi?id=12841#c3 suffice?
(In reply to Florian Hubold from comment #10) > (In reply to claire robinson from comment #9) > > Testing complete mga4 32 > > > > Florian do you want us to validate this now for mga4 and you create a > > separate bug for mga3 or should we wait now until the mga3 updates are ready > > and push both together? > > Whatever is less work. I don't think it makes a difference in the amount of work. If the mga3 packages will be ready soonish it'd be fine to wait. If not, we should probably get the ones that are ready out there. It's up to you. > > We'll need an advisory though before we can do either, depending how you > > want to handle it. > > Doesn't https://bugs.mageia.org/show_bug.cgi?id=12841#c3 suffice? It's a start. I'll reformat it into an advisory when I'm back at work, hopefully tomorrow.
(In reply to David Walser from comment #11) > (In reply to Florian Hubold from comment #10) > > (In reply to claire robinson from comment #9) > > > Testing complete mga4 32 > > > > > > Florian do you want us to validate this now for mga4 and you create a > > > separate bug for mga3 or should we wait now until the mga3 updates are ready > > > and push both together? > > > > Whatever is less work. > > I don't think it makes a difference in the amount of work. If the mga3 > packages will be ready soonish it'd be fine to wait. If not, we should > probably get the ones that are ready out there. It's up to you. That's a point. So best push the packages we have currently, I will clone the bug for mga3 in the next days.
Thanks Florian. Awaiting the advisory then David please.
Whiteboard: MGA3TOO has_procedure mga4-32-ok mga4-64-ok => has_procedure mga4-32-ok mga4-64-ok
Blocks: (none) => 13336
We can use the advisory text from Mandriva's update. Advisory: ======================== Updated postgresql packages fix security vulnerabilities: Granting a role without ADMIN OPTION is supposed to prevent the grantee from adding or removing members from the granted role, but this restriction was easily bypassed by doing SET ROLE first. The security impact is mostly that a role member can revoke the access of others, contrary to the wishes of his grantor. Unapproved role member additions are a lesser concern, since an uncooperative role member could provide most of his rights to others anyway by creating views or SECURITY DEFINER functions (CVE-2014-0060). The primary role of PL validator functions is to be called implicitly during CREATE FUNCTION, but they are also normal SQL functions that a user can call explicitly. Calling a validator on a function actually written in some other language was not checked for and could be exploited for privilege-escalation purposes. The fix involves adding a call to a privilege-checking function in each validator function. Non-core procedural languages will also need to make this change to their own validator functions, if any (CVE-2014-0061). If the name lookups come to different conclusions due to concurrent activity, we might perform some parts of the DDL on a different table than other parts. At least in the case of CREATE INDEX, this can be used to cause the permissions checks to be performed against a different table than the index creation, allowing for a privilege escalation attack (CVE-2014-0062). The MAXDATELEN constant was too small for the longest possible value of type interval, allowing a buffer overrun in interval_out(). Although the datetime input functions were more careful about avoiding buffer overrun, the limit was short enough to cause them to reject some valid inputs, such as input containing a very long timezone name. The ecpg library contained these vulnerabilities along with some of its own (CVE-2014-0063). Several functions, mostly type input functions, calculated an allocation size without checking for overflow. If overflow did occur, a too-small buffer would be allocated and then written past (CVE-2014-0064). Use strlcpy() and related functions to provide a clear guarantee that fixed-size buffers are not overrun. Unlike the preceding items, it is unclear whether these cases really represent live issues, since in most cases there appear to be previous constraints on the size of the input string. Nonetheless it seems prudent to silence all Coverity warnings of this type (CVE-2014-0065). There are relatively few scenarios in which crypt() could return NULL, but contrib/chkpass would crash if it did. One practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms (e.g., FIPS mode) (CVE-2014-0066). Since the temporary server started by make check uses trust authentication, another user on the same machine could connect to it as database superuser, and then potentially exploit the privileges of the operating-system user who started the tests. A future release will probably incorporate changes in the testing procedure to prevent this risk, but some public discussion is needed first. So for the moment, just warn people against using make check when there are untrusted users on the same machine (CVE-2014-0067). This update provides PostgreSQL versions 9.3.4, 9.2.8, 9.1.13, and 9.0.17 that fix these issues, as well as several others. See the links in the upstream release announcements for more details. The postgresql9.3 update also fixes an issue where the /var/run/postgresql directory was not created when the package is first installed (mga#13241). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0060 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0061 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0062 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0063 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0064 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0065 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0066 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0067 http://article.gmane.org/gmane.comp.db.postgresql.announce/2371 http://article.gmane.org/gmane.comp.db.postgresql.announce/2386 http://www.mandriva.com/en/support/security/advisories/mbs1/MDVSA-2014:047/ https://bugs.mageia.org/show_bug.cgi?id=13241 https://bugs.mageia.org/show_bug.cgi?id=12841
Validating. Advisory uploaded. Could sysadmin please push to 4 updates (3 is now being updated separately) Thanks
Keywords: (none) => validated_updateWhiteboard: has_procedure mga4-32-ok mga4-64-ok => has_procedure advisory mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0205.html
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
Apparently this also fixed CVE-2014-2669: http://lwn.net/Vulnerabilities/610420/