Message-Id: <E1WGtTp-00018A-OJ@titan.mandriva.com>
Date: Fri, 21 Feb 2014 18:01:41 +0100
From: security@...driva.com
To: full-disclosure@...ts.grok.org.uk
Subject: [ MDVSA-2014:047 ] postgresql

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 _______________________________________________________________________

 Mandriva Linux Security Advisory                         MDVSA-2014:047
 http://www.mandriva.com/en/support/security/
 _______________________________________________________________________

 Package : postgresql
 Date    : February 21, 2014
 Affected: Business Server 1.0
 _______________________________________________________________________

 Problem Description:

 Multiple vulnerabilities has been discovered and corrected in
 postgresql:
 
 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 advisory provides the latest version of PostgreSQL that is not
 vulnerable to these issues.
 _______________________________________________________________________

 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://www.postgresql.org/docs/9.2/static/release-9-2-5.html
 http://www.postgresql.org/docs/9.2/static/release-9-2-6.html
 http://www.postgresql.org/docs/9.2/static/release-9-2-7.html
 _______________________________________________________________________

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 79694cb7b4dd67569529507531e9f43c  mbs1/x86_64/lib64ecpg9.2_6-9.2.7-1.mbs1.x86_64.rpm
 71413fef641ef26dfd364cc0417ec002  mbs1/x86_64/lib64pq9.2_5-9.2.7-1.mbs1.x86_64.rpm
 3cac01a8f005e1b66c8f5e5f2beb500e  mbs1/x86_64/postgresql9.2-9.2.7-1.mbs1.x86_64.rpm
 6fa82ca3338f6b621a1224107e82c4a2  mbs1/x86_64/postgresql9.2-contrib-9.2.7-1.mbs1.x86_64.rpm
 713b25468183ad23d7db2c95367def9c  mbs1/x86_64/postgresql9.2-devel-9.2.7-1.mbs1.x86_64.rpm
 f88d066354f88a3cc7c65bafb4dba438  mbs1/x86_64/postgresql9.2-docs-9.2.7-1.mbs1.noarch.rpm
 6b98f768d9345669d883b5d24493726e  mbs1/x86_64/postgresql9.2-pl-9.2.7-1.mbs1.x86_64.rpm
 eb75e37124d82a102335fe7cdfdc1ba9  mbs1/x86_64/postgresql9.2-plperl-9.2.7-1.mbs1.x86_64.rpm
 213b461056d052adc26a681a415a3390  mbs1/x86_64/postgresql9.2-plpgsql-9.2.7-1.mbs1.x86_64.rpm
 bfd35ced63664bd21f38d92729e94b0d  mbs1/x86_64/postgresql9.2-plpython-9.2.7-1.mbs1.x86_64.rpm
 18d86e7a4b61656b1b1dc7bdf67c45fc  mbs1/x86_64/postgresql9.2-pltcl-9.2.7-1.mbs1.x86_64.rpm
 ea94bae659957662f9247b13285391e8  mbs1/x86_64/postgresql9.2-server-9.2.7-1.mbs1.x86_64.rpm 
 f512d51c07fa28546fa2dbbbebfe04f9  mbs1/SRPMS/postgresql9.2-9.2.7-1.mbs1.src.rpm
 _______________________________________________________________________

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/en/support/security/advisories/

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 _______________________________________________________________________

 Type Bits/KeyID     Date       User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  <security*mandriva.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iD8DBQFTB4WfmqjQ0CJFipgRAlaqAJ9bkVWpCWdqrmS8++MyfhjKFCcLPgCcC0xe
JhShzLbEybporLpUPXpdFgQ=
=Ky+m
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists