mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update release notes with security issues.

Browse Source 
Security: CVE-2010-1169, CVE-2010-1170
This commit is contained in:
Tom Lane 2010-05-13 21:27:08 +00:00
parent 0554358756
commit 9d4e01ca3e
6 changed files with 248 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
doc/src/sgml/release-7.4.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-7.4.sgml,v 1.1.12.5 2010/05/12 23:27:25 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-7.4.sgml,v 1.1.12.6 2010/05/13 21:27:07 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-7-4-29">
@ -37,6 +37,46 @@
<itemizedlist>
<listitem>
<para>
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Do not allow an unprivileged user to reset superuser-only parameter

42
doc/src/sgml/release-8.0.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.0.sgml,v 1.1.10.5 2010/05/12 23:27:25 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.0.sgml,v 1.1.10.6 2010/05/13 21:27:07 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-8-0-25">
@ -37,6 +37,46 @@
<itemizedlist>
<listitem>
<para>
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Do not allow an unprivileged user to reset superuser-only parameter

42
doc/src/sgml/release-8.1.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.1.sgml,v 1.1.8.5 2010/05/12 23:27:25 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.1.sgml,v 1.1.8.6 2010/05/13 21:27:07 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-8-1-21">
@ -31,6 +31,46 @@
<itemizedlist>
<listitem>
<para>
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Do not allow an unprivileged user to reset superuser-only parameter

42
doc/src/sgml/release-8.2.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.2.sgml,v 1.1.6.5 2010/05/12 23:27:25 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.2.sgml,v 1.1.6.6 2010/05/13 21:27:07 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-8-2-17">
@ -31,6 +31,46 @@
<itemizedlist>
<listitem>
<para>
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Fix possible crash if a cache reset message is received during

42
doc/src/sgml/release-8.3.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.3.sgml,v 1.1.4.5 2010/05/12 23:27:26 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.3.sgml,v 1.1.4.6 2010/05/13 21:27:08 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-8-3-11">
@ -31,6 +31,46 @@
<itemizedlist>
<listitem>
<para>
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Fix possible crash if a cache reset message is received during

46
doc/src/sgml/release-8.4.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.4.sgml,v 1.12.2.6 2010/05/12 23:27:26 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-8.4.sgml,v 1.12.2.7 2010/05/13 21:27:08 tgl Exp $ -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-8-4-4">
@ -33,8 +33,48 @@
<listitem>
<para>
Fix error during WAL replay of <literal>ALTER ... SET TABLESPACE</>
(Tom)
Enforce restrictions in <literal>plperl</> using an opmask applied to
the whole interpreter, instead of using <filename>Safe.pm</>
(Tim Bunce, Andrew Dunstan)
</para>
<para>
Recent developments have convinced us that <filename>Safe.pm</> is too
insecure to rely on for making <literal>plperl</> trustable. This
change removes use of <filename>Safe.pm</> altogether, in favor of using
a separate interpreter with an opcode mask that is always applied.
Pleasant side effects of the change include that it is now possible to
use Perl's <literal>strict</> pragma in a natural way in
<literal>plperl</>, and that Perl's <literal>$a</> and <literal>$b</>
variables work as expected in sort routines, and that function
compilation is significantly faster. (CVE-2010-1169)
</para>
</listitem>
<listitem>
<para>
Prevent PL/Tcl from executing untrustworthy code from
<structname>pltcl_modules</> (Tom)
</para>
<para>
PL/Tcl's feature for autoloading Tcl code from a database table
could be exploited for trojan-horse attacks, because there was no
restriction on who could create or insert into that table. This change
disables the feature unless <structname>pltcl_modules</> is owned by a
superuser. (However, the permissions on the table are not checked, so
installations that really need a less-than-secure modules table can
still grant suitable privileges to trusted non-superusers.) Also,
prevent loading code into the unrestricted <quote>normal</> Tcl
interpreter unless we are really going to execute a <literal>pltclu</>
function. (CVE-2010-1170)
</para>
</listitem>
<listitem>
<para>
Fix data corruption during WAL replay of
<literal>ALTER ... SET TABLESPACE</> (Tom)
</para>
<para>