Note: This is an archival copy of Security Sun Alert 201751 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001291.1.
Solaris 10 Operating System
Date of Workaround Release
Date of Resolved Release
Two security vulnerabilities in the PostgreSQL database server (see postgres(1)) may allow local or remote PostgreSQL users the ability to cause the PostgreSQL server to crash or access restricted database content.
The ability to crash the PostgreSQL server is a type of Denial of Service (DoS).
These issues are described in the following documents:
These issues can occur in the following releases:
Note 1: Solaris 8 and Solaris 9 do not ship with PostgreSQL and are thus not impacted by this issue.
Note 2: CVE-2007-0555 affects PostgreSQL versions 7.3 before 7.3.13, 7.4 before 7.4.16, 8.0 before 8.0.11, 8.1 before 8.1.7, and 8.2 before 8.2.2. CVE-2007-0556 affects PostgreSQL versions 8.0 before 8.0.11, 8.1 before 8.1.7, and 8.2 before 8.2.2.
Note 3: Any user exploiting these vulnerabilities must have an account on the SQL server and additional permissions to create or alter objects in the database/schema is necessary for CVE-2007-0555. These permissions are available by default to all such users.
Note 4: Solaris 10 6/06 was the first release of Solaris to ship PostgreSQL and it included version 8.1.3. The patches in the "Resolution" section below update PostgreSQL to version 8.1.8.
To determine the version of PostgreSQL on the system, the following command can be run:
$ /usr/bin/postgres --version postgres (PostgreSQL) 8.1.3
If the described issue occurs, The PostgreSQL server process may exit unexpectedly with the following messages in the log file:
LOG: server process (PID 2917) was terminated by signal 11 LOG: terminating any other active server processes FATAL: the database system is in recovery mode LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2007-02-09 08:56:28 CET
The log file is stored in the "data" directory by default. The following stack trace is indicative of this issue:
feb3458b memcpy (2a, 0, 8) + 1b 08119bb7 postquel_execute (83ac8d8, 8046abc, 83ac418, 83129e0) + 7f 08119cf8 fmgr_sql (8046abc) + 91 08114f96 ExecMakeFunctionResult (83abd20, 83abc98, 83ac2a8, 83ac300) + 134 0811574e ExecEvalFunc (83abd20, 83abc98, 83ac2a8, 83ac300) + 31 08117e0a ExecTargetList (83ac178, 83abc98, 83ac298, 83ac2a8, 83ac300, 8046d80) + 6b 081180a8 ExecProject (83ac2b8, 8046d80) + 59 0811fce0 ExecResult (83abc10) + 9c 08113eae ExecProcNode (83abc10) + 162 081129bf ExecutePlan (83abb00, 83abc10, 1, 0, 1, 8355470) + 83 08111fe5 ExecutorRun (83a8fe8, 1, 0) + 53 081852d9 PortalRunSelect (83a6fb8, 1, 0, 8355470) + 177 081850a1 PortalRun (83a6fb8, 7fffffff, 8355470, 8355470, 80470d8) + 2dc 0818187c exec_simple_query (8354e88) + 285 08184179 PostgresMain (4, 82f4a38, 82f4a08) + eee 0816393f BackendRun (830cb10, 830cb10, 1, 45cc292c, 8047d74, 81618db) + 4bd 08163271 BackendStartup (830cb10) + 4b 081618db ServerLoop (313c1, 82f0708, 3, 82f8b48, 3, febb07a7) + 12f 081611b7 PostmasterMain (3, 82f0708) + 9c3 0812c3c5 main (3, 8047de0, 8047df0) + 1e5 0807ef7a ???????? (3, 8047ea0, 8047fe1, 8047fe1, 0, 8047ec5)
To work around the issue described in CVE-2007-0555, remove permissions to create or alter objects in the database schema to all users by using the following command:
REVOKE CREATE ON SCHEMA public FROM PUBLIC CASCADE;
Note: All users have this permission on public schema by default.
For more information about REVOKE command see: http://www.postgresql.org/docs/8.1/interactive/sql-revoke.html
There is no workaround for the issue described in CVE-2007-0556. Please see the "Resolution" section below.
This issue is addressed in the following releases:
This solution has no attachment