Multiple vulnerabilities was discovered and corrected in postgresql: An authenticated database user can manipulate modules and tied variables in some external procedural languages to execute code with enhanced privileges (CVE-2010-3433). Reproducible: Always
The security issues lie in dev-db/postgresql-server.
*** Bug 340805 has been marked as a duplicate of this bug. ***
From http://www.postgresql.org/about/news.1244: The PostgreSQL Global Development Group today released security updates for all active branches of the PostgreSQL object-relational database system, including versions 9.0.1, 8.4.5, 8.3.12, 8.2.18, 8.1.22, 8.0.26 and 7.4.30. This is the final update for PostgreSQL versions 7.4 and 8.0. [...] The security vulnerability allows any ordinary SQL users with "trusted" procedural language usage rights to modify the contents of procedural language functions at runtime. As detailed in CVE-2010-3433, an authenticated user can accomplish privilege escalation by hijacking a SECURITY DEFINER function (or some other existing authentication-change operation). The mere presence of the procedural languages does not make your database application vulnerable. Fixed versions are already in the tree. Postgresql herd, are these the right targets for stabilization? dev-db/postgresql-docs-{8.1.22,8.2.18,8.3.12,8.4.5} dev-db/postgresql-base-{8.1.22,8.2.18,8.3.12,8.4.5} dev-db/postgresql-server-{8.1.22,8.2.18,8.3.12,8.4.5} Thank you.
Yes.
(In reply to comment #4) > Yes. > Thanks, Aaron. Arches, please test and mark the following stable. =dev-db/postgresql-docs-{8.1.22,8.2.18,8.3.12,8.4.5} =dev-db/postgresql-base-{8.1.22,8.2.18,8.3.12,8.4.5} =dev-db/postgresql-server-{8.1.22,8.2.18,8.3.12,8.4.5} Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" ppc does not have 8.1.x keyworded, and ppc64 does not have 8.1.x or 8.2.x keyworded, so those do not need to be stabilized here.
I get some test failures on the server packages. Can we go on? Has anyone tested functionality of those packages?
(In reply to comment #6) > I get some test failures on the server packages. Can we go on? Has anyone > tested functionality of those packages? > What are the failures?
(In reply to comment #7) > What are the failures? > ============== initializing database system ============== pg_regress: initdb failed Examine ./log/initdb.log for the reason. make[2]: *** [check] Error 2 Cristian, your error is same?
On amd64: =dev-db/postgresql-docs-{8.1.22,8.2.18,8.3.12,8.4.5}: OK =dev-db/postgresql-base-{8.1.22,8.2.18,8.3.12,8.4.5}: OK =dev-db/postgresql-server-{8.1.22,8.2.18,8.3.12,8.4.5}: Alls Fail test 8.2.18 does not respect LDFLAGS 8.3.12 does not respect LDFLAGS 8.4.5 does not respect LDFLAGS it is obvious that it is more important security, than respect ldflags, anyway, I'll open new bug for this.
I get the same error on ppc64 64UL. proceed in stabilizing or what?
Why do arch devs keep complaining on stabilisation/security bugs - file a new bug report and make it block the stabilisation/security bug, like bug #347223 does...
x86 stable nonetheless.
Stable for HPPA PPC.
I've tried having a go at this on alpha, to no avail. Details similar as for hppa (but I got several futile steps further), see bug 347223.
amd64 done. Thanks Agostino
Stable on alpha. Note: I normally would not commit this since a failing test suite in the case of a DB is a show stopper for me personally. However, I can see that postgres is basically unmaintained on alpha and this is a security bug. Hence, I reluctantly stabilized on alpha.
arm/ia64/s390/sh/sparc stable
ppc64 stable, last arch done
Thanks, folks. GLSA Vote: No.
I believe there should be a GLSA. It has been a bit more than three years since the last GLSA regarding PostgreSQL had been published. There are still folks running the antiquated dev-db/{libpq,postgresql} ebuilds. We need something to encourage them to move on to dev-db/postgresql-{docs,base,server}, and a GLSA that exposes the risks they're facing might just do it. Furthermore, there are six other security bugs open against dev-db/postgresql-server that have yet to be closed. (308063, 313335, 297383, 261223, 284274, 320967) Some of these bugs are against versions that are no longer in the tree. The oldest bug is nearly two years old. A GLSA request has been filed on another, apparently, more than five months ago, yet nothing has been released. In short, some of the security bugs are fairly serious and we have yet to make an announcement about them. A GLSA that wraps all of them up would certainly be a good thing.
CVE-2010-3433 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3433): The PL/perl and PL/Tcl implementations in PostgreSQL 7.4 before 7.4.30, 8.0 before 8.0.26, 8.1 before 8.1.22, 8.2 before 8.2.18, 8.3 before 8.3.12, 8.4 before 8.4.5, and 9.0 before 9.0.1 do not properly protect script execution by a different SQL user identity within the same session, which allows remote authenticated users to gain privileges via crafted script code in a SECURITY DEFINER function, as demonstrated by (1) redefining standard functions or (2) redefining operators, a different vulnerability than CVE-2010-1168, CVE-2010-1169, CVE-2010-1170, and CVE-2010-1447.
GLSA with the other pgsql bugs
This issue was resolved and addressed in GLSA 201110-22 at http://security.gentoo.org/glsa/glsa-201110-22.xml by GLSA coordinator Alex Legler (a3li).