Advisories ยป MGASA-2014-0222

Updated postgresql packages fix multiple vulnerabilities

Publication date: 17 May 2014
Modification date: 17 May 2014
Type: security
Affected Mageia releases : 3
CVE: CVE-2014-0060 , CVE-2014-0061 , CVE-2014-0062 , CVE-2014-0063 , CVE-2014-0064 , CVE-2014-0065 , CVE-2014-0066 , CVE-2014-0067

Description

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).

See the links in the upstream release announcements for more details.

References

SRPMS

3/core