[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1WGtTp-000183-Gk@titan.mandriva.com>
Date: Fri, 21 Feb 2014 18:01:41 +0100
From: security@...driva.com
To: bugtraq@...urityfocus.com
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-----
Powered by blists - more mailing lists