Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 91231 - dev-db/postgresql two new PostgreSQL security problems (CAN-2005-1409, CAN-2005-1410)
Summary: dev-db/postgresql two new PostgreSQL security problems (CAN-2005-1409, CAN-20...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://www.postgresql.org
Whiteboard: B3? [glsa] jaervosz
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-02 14:31 UTC by James Bannon
Modified: 2020-04-04 20:58 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Bannon 2005-05-02 14:31:43 UTC
Not sure if this should be registered as a bug as it's not really gentoo-specific but I thought it was worthy of notification to the developers and other postgresql users. Here is the text of the latest security announcement.

Two serious security errors have been found in PostgreSQL 7.3 and newer
releases.  These errors at least allow an unprivileged database user to
crash the backend process, and may make it possible for an unprivileged
user to gain the privileges of a database superuser.

We are currently preparing new releases that will correct these problems
in freshly initdb'd installations.  However, because these problems are
really incorrect system catalog entries, updating to a new release will
NOT by itself solve the problems in an existing installation.  Instead,
it is necessary for the database administrator to fix the catalog entries
manually, as described below.  We are releasing this advisory to encourage
administrators of PostgreSQL installations to perform these fixes as soon
as possible.


Character conversion vulnerability
----------------------------------

The more severe of the two errors is that the functions that support
client-to-server character set conversion can be called from SQL commands
by unprivileged users, but these functions are not designed to be safe
against malicious choices of argument values.  This problem exists in
PostgreSQL 7.3.* through 8.0.*.  The recommended fix is to disable public
EXECUTE access for these functions.  This does not affect normal usage of
the functions for character set conversion, but it will prevent misuse.

To accomplish this change, execute the following SQL command as a
superuser:

        UPDATE pg_proc SET proacl = '{=}'
        WHERE pronamespace = 11 AND pronargs = 5
              AND proargtypes[2] = 'cstring'::regtype;

In 7.3.* through 8.0.*, this should report having updated 90 rows.
7.4 and later will report a "WARNING: defaulting grantor to user ID 1"
which can be ignored.

The above command must be carried out in *each* database of an
installation, including template1, and ideally including template0 as
well.  If you do not fix the template databases then any subsequently
created databases will contain the same vulnerability.  template1 can
be fixed in the same way as any other database, but fixing template0
requires additional steps. First, from any database issue

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

Next connect to template0 and perform the pg_proc update. Finally, do 

-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';


tsearch2 vulnerability
----------------------

The other error is that the contrib/tsearch2 module misdeclares several
functions as returning type "internal" when they do not have any
"internal" argument.  This breaks the type safety of "internal" by
allowing users to construct SQL commands that invoke other functions
accepting "internal" arguments.  The consequences of this have not been
investigated in detail, but it is certainly at least possible to crash
the backend.

This error affects PostgreSQL 7.4 and later, but only if you have
installed the contrib/tsearch2 module.  The recommended fix is to
change the misdeclared functions so that they accept an "internal"
argument and therefore cannot be called directly from SQL commands.
To do this, execute the following command as a superuser:

        UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
        WHERE oid IN (
                'dex_init(text)'::regprocedure,
                'snb_en_init(text)'::regprocedure,
                'snb_ru_init(text)'::regprocedure,
                'spell_init(text)'::regprocedure,
                'syn_init(text)'::regprocedure
        );

This should report 5 rows updated.  (If it fails with a message
like "function "dex_init(text)" does not exist", then either tsearch2
is not installed in this database, or you already did the update.)

You will need to do this in *each* database in which you have installed
tsearch2, including template1.  You need not worry about template0,
however, since it will certainly not contain tsearch2.

If you frequently install tsearch2 in new databases, you will also
want to modify the tsearch.sql script to declare these functions as
taking type internal in the first place.  (The script fix will be part
of the upcoming releases, so you may be able to wait for those.)


On behalf of the PostgreSQL core committee, I'd like to apologize for
any problems that may arise from these errors.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reproducible: Always
Steps to Reproduce:
1. See details
2.
3.

Actual Results:  
See above,

Expected Results:  
The security issues should not have been there.

Not relevant.
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-02 22:35:27 UTC
postgresql please advise.
Comment 2 Adir Abraham 2005-05-04 13:53:54 UTC
More details are found http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1409 and a confirm in http://www.postgresql.org/about/news.315
Comment 3 Adir Abraham 2005-05-05 04:52:17 UTC
The two vulnerabilities can cause a DoS. I recommend setting it to B3.

Secunia advises on postgresql security patches from Ubuntu. Check http://secunia.com/advisories/15248/
Comment 4 MATSUU Takuto (RETIRED) gentoo-dev 2005-05-07 01:35:42 UTC
7.4.7-r2
8.0.1-r3
8.0.2-r1
in cvs.
Comment 5 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-07 01:47:55 UTC
Arches please test and mark stable.

Target keywords:

7.4.7-r2: x86 ppc sparc mips alpha arm hppa amd64 ia64 s390 ppc64
8.0.1-r3: x86 ppc sparc ~mips alpha arm hppa amd64 ia64 s390 ppc64
Comment 6 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-05-07 02:34:04 UTC
Stable on ppc.
Comment 7 Jeffrey Forman (RETIRED) gentoo-dev 2005-05-07 05:43:18 UTC
stable on sparc
Comment 8 Konstantin Arkhipov (RETIRED) gentoo-dev 2005-05-07 05:52:16 UTC
stable on amd64
Comment 9 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-05-07 05:58:23 UTC
Stable on hppa.
Comment 10 Omkhar Arasaratnam (RETIRED) gentoo-dev 2005-05-07 10:12:18 UTC
Stable on ppc64
Comment 11 Bryan Østergaard (RETIRED) gentoo-dev 2005-05-07 13:30:01 UTC
Stable on alpha + ia64.
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-11 07:19:55 UTC
x86 please test and mark stable.
Comment 13 SpanKY gentoo-dev 2005-05-12 19:20:47 UTC
arm/s390 stable
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-14 03:11:32 UTC
Please mark stable on x86
Comment 15 Masatomo Nakano (RETIRED) gentoo-dev 2005-05-14 21:03:37 UTC
stable on x86
Comment 16 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-15 00:06:20 UTC
Thx Masatomo.

This one is ready for GLSA decision, I vote a full YES.
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2005-05-15 02:18:28 UTC
Yes too
Comment 18 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-15 04:11:51 UTC
GLSA 2005-12