New security/bug fix releases: 8.4.5, 8.3.12, 8.1.22

Bug #655293 reported by Martin Pitt on 2010-10-05
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
postgresql-8.1 (Ubuntu)
Undecided
Unassigned
Dapper
High
Martin Pitt
Hardy
Undecided
Unassigned
Jaunty
Undecided
Unassigned
Karmic
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
postgresql-8.3 (Ubuntu)
Undecided
Unassigned
Dapper
Undecided
Unassigned
Hardy
High
Unassigned
Jaunty
High
Martin Pitt
Karmic
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
postgresql-8.4 (Ubuntu)
High
Martin Pitt
Dapper
Undecided
Unassigned
Hardy
Undecided
Unassigned
Jaunty
Undecided
Unassigned
Karmic
Undecided
Unassigned
Lucid
High
Unassigned
Maverick
High
Martin Pitt

Bug Description

Binary package hint: postgresql-8.4

Today, PostgreSQL released new security/bug fix microreleases. Please see http://www.postgresql.org/about/news.1244 for the details of the announcement.

Martin Pitt (pitti) on 2010-10-05
Changed in postgresql-8.4 (Ubuntu Dapper):
status: New → Invalid
Changed in postgresql-8.4 (Ubuntu Hardy):
status: New → Invalid
Changed in postgresql-8.4 (Ubuntu Jaunty):
status: New → Invalid
Changed in postgresql-8.4 (Ubuntu Maverick):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
Changed in postgresql-8.4 (Ubuntu Lucid):
importance: Undecided → High
visibility: private → public
Changed in postgresql-8.4 (Ubuntu Maverick):
status: New → In Progress
Changed in postgresql-8.4 (Ubuntu Lucid):
status: New → In Progress
Changed in postgresql-8.4 (Ubuntu Karmic):
status: New → In Progress
Changed in postgresql-8.3 (Ubuntu Maverick):
status: New → Invalid
Changed in postgresql-8.3 (Ubuntu Lucid):
status: New → Invalid
Changed in postgresql-8.1 (Ubuntu Maverick):
status: New → Invalid
Changed in postgresql-8.3 (Ubuntu Karmic):
status: New → Invalid
Changed in postgresql-8.1 (Ubuntu Lucid):
status: New → Invalid
Changed in postgresql-8.3 (Ubuntu Jaunty):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Changed in postgresql-8.1 (Ubuntu Karmic):
status: New → Invalid
Changed in postgresql-8.3 (Ubuntu Dapper):
status: New → Invalid
Changed in postgresql-8.1 (Ubuntu Jaunty):
status: New → Invalid
Changed in postgresql-8.3 (Ubuntu Hardy):
importance: Undecided → High
status: New → In Progress
Changed in postgresql-8.1 (Ubuntu Hardy):
status: New → Invalid
Changed in postgresql-8.1 (Ubuntu Dapper):
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) wrote :

@ubuntu-release: I just uploaded 8.4.5-1 to Debian unstable. It passes the upstream as well as the postgresql-common test suites. Can I still sync that into maverick, or do you prefer an USN for this?

Martin Pitt (pitti) wrote :

Lucid and Karmic updates are in

  http://people.canonical.com/~pitti/packages/psql/lucid/
  http://people.canonical.com/~pitti/packages/psql/karmic/

will continue with the other releases tomorrow.

Changed in postgresql-8.4 (Ubuntu Maverick):
status: In Progress → Fix Committed
Martin Pitt (pitti) on 2010-10-06
Changed in postgresql-8.3 (Ubuntu Jaunty):
status: In Progress → Fix Committed
Changed in postgresql-8.1 (Ubuntu Dapper):
assignee: nobody → Martin Pitt (pitti)
status: In Progress → Fix Committed
Marc Deslauriers (mdeslaur) wrote :

Thanks for the packages, I'll build them as security updates now.

Launchpad Janitor (janitor) wrote :
Download full text (8.2 KiB)

This bug was fixed in the package postgresql-8.4 - 8.4.5-0ubuntu10.04

---------------
postgresql-8.4 (8.4.5-0ubuntu10.04) lucid-security; urgency=low

  * New upstream security/bug fix update: (LP: #655293)
    - Use a separate interpreter for each calling SQL userid in PL/Perl
      and PL/Tcl.
      This change prevents security problems that can be caused by
      subverting Perl or Tcl code that will be executed later in the same
      session under another SQL user identity (for example, within a
      SECURITY DEFINER function). Most scripting languages offer numerous
      ways that that might be done, such as redefining standard functions
      or operators called by the target function. Without this change,
      any SQL user with Perl or Tcl language usage rights can do
      essentially anything with the SQL privileges of the target
      function's owner.
      The cost of this change is that intentional communication among
      Perl and Tcl functions becomes more difficult. To provide an escape
      hatch, PL/PerlU and PL/TclU functions continue to use only one
      interpreter per session. This is not considered a security issue
      since all such functions execute at the trust level of a database
      superuser already.
      It is likely that third-party procedural languages that claim to
      offer trusted execution have similar security issues. We advise
      contacting the authors of any PL you are depending on for
      security-critical purposes.
      Our thanks to Tim Bunce for pointing out this issue
      (CVE-2010-3433).
    - Prevent possible crashes in pg_get_expr() by disallowing it from
      being called with an argument that is not one of the system catalog
      columns it's intended to be used with.
    - Fix incorrect placement of placeholder evaluation.
      This bug could result in query outputs being non-null when they
      should be null, in cases where the inner side of an outer join is a
      sub-select with non-strict expressions in its output list.
    - Fix possible duplicate scans of UNION ALL member relations.
    - Fix "cannot handle unplanned sub-select" error.
      This occurred when a sub-select contains a join alias reference
      that expands into an expression containing another sub-select.
    - Fix mishandling of whole-row Vars that reference a view or
      sub-select and appear within a nested sub-select.
    - Fix mishandling of cross-type IN comparisons.
      This could result in failures if the planner tried to implement an
      IN join with a sort-then-unique-then-plain-join plan.
    - Fix computation of "ANALYZE" statistics for tsvector columns.
      The original coding could produce incorrect statistics, leading to
      poor plan choices later.
    - Improve planner's estimate of memory used by array_agg(),
      string_agg(), and similar aggregate functions.
      The previous drastic underestimate could lead to out-of-memory
      failures due to inappropriate choice of a hash-aggregation plan.
    - Fix failure to mark cached plans as transient.
      If a plan is prepared while "CREATE INDEX CONCURRENTLY" is in
      progress for one of the referenced tables...

Read more...

Launchpad Janitor (janitor) wrote :
Download full text (8.2 KiB)

This bug was fixed in the package postgresql-8.4 - 8.4.5-0ubuntu9.10

---------------
postgresql-8.4 (8.4.5-0ubuntu9.10) karmic-security; urgency=low

  * New upstream security/bug fix update: (LP: #655293)
    - Use a separate interpreter for each calling SQL userid in PL/Perl
      and PL/Tcl.
      This change prevents security problems that can be caused by
      subverting Perl or Tcl code that will be executed later in the same
      session under another SQL user identity (for example, within a
      SECURITY DEFINER function). Most scripting languages offer numerous
      ways that that might be done, such as redefining standard functions
      or operators called by the target function. Without this change,
      any SQL user with Perl or Tcl language usage rights can do
      essentially anything with the SQL privileges of the target
      function's owner.
      The cost of this change is that intentional communication among
      Perl and Tcl functions becomes more difficult. To provide an escape
      hatch, PL/PerlU and PL/TclU functions continue to use only one
      interpreter per session. This is not considered a security issue
      since all such functions execute at the trust level of a database
      superuser already.
      It is likely that third-party procedural languages that claim to
      offer trusted execution have similar security issues. We advise
      contacting the authors of any PL you are depending on for
      security-critical purposes.
      Our thanks to Tim Bunce for pointing out this issue
      (CVE-2010-3433).
    - Prevent possible crashes in pg_get_expr() by disallowing it from
      being called with an argument that is not one of the system catalog
      columns it's intended to be used with.
    - Fix incorrect placement of placeholder evaluation.
      This bug could result in query outputs being non-null when they
      should be null, in cases where the inner side of an outer join is a
      sub-select with non-strict expressions in its output list.
    - Fix possible duplicate scans of UNION ALL member relations.
    - Fix "cannot handle unplanned sub-select" error.
      This occurred when a sub-select contains a join alias reference
      that expands into an expression containing another sub-select.
    - Fix mishandling of whole-row Vars that reference a view or
      sub-select and appear within a nested sub-select.
    - Fix mishandling of cross-type IN comparisons.
      This could result in failures if the planner tried to implement an
      IN join with a sort-then-unique-then-plain-join plan.
    - Fix computation of "ANALYZE" statistics for tsvector columns.
      The original coding could produce incorrect statistics, leading to
      poor plan choices later.
    - Improve planner's estimate of memory used by array_agg(),
      string_agg(), and similar aggregate functions.
      The previous drastic underestimate could lead to out-of-memory
      failures due to inappropriate choice of a hash-aggregation plan.
    - Fix failure to mark cached plans as transient.
      If a plan is prepared while "CREATE INDEX CONCURRENTLY" is in
      progress for one of the referenced tables,...

Read more...

Launchpad Janitor (janitor) wrote :
Download full text (5.8 KiB)

This bug was fixed in the package postgresql-8.3 - 8.3.12-0ubuntu9.04

---------------
postgresql-8.3 (8.3.12-0ubuntu9.04) jaunty-security; urgency=low

  * New upstream security/bug fix release: (LP: #655293)
    - Use a separate interpreter for each calling SQL userid in PL/Perl
      and PL/Tcl.
      This change prevents security problems that can be caused by
      subverting Perl or Tcl code that will be executed later in the same
      session under another SQL user identity (for example, within a
      SECURITY DEFINER function). Most scripting languages offer numerous
      ways that that might be done, such as redefining standard functions
      or operators called by the target function. Without this change,
      any SQL user with Perl or Tcl language usage rights can do
      essentially anything with the SQL privileges of the target
      function's owner.
      The cost of this change is that intentional communication among
      Perl and Tcl functions becomes more difficult. To provide an escape
      hatch, PL/PerlU and PL/TclU functions continue to use only one
      interpreter per session. This is not considered a security issue
      since all such functions execute at the trust level of a database
      superuser already.
      It is likely that third-party procedural languages that claim to
      offer trusted execution have similar security issues. We advise
      contacting the authors of any PL you are depending on for
      security-critical purposes.
      Our thanks to Tim Bunce for pointing out this issue
      (CVE-2010-3433).
    - Prevent possible crashes in pg_get_expr() by disallowing it from
      being called with an argument that is not one of the system catalog
      columns it's intended to be used with.
    - Fix incorrect usage of non-strict OR joinclauses in Append
      indexscans.
      This is a back-patch of an 8.4 fix that was missed in the 8.3
      branch. This corrects an error introduced in 8.3.8 that could cause
      incorrect results for outer joins when the inner relation is an
      inheritance tree or UNION ALL subquery.
    - Fix possible duplicate scans of UNION ALL member relations.
    - Fix "cannot handle unplanned sub-select" error.
      This occurred when a sub-select contains a join alias reference
      that expands into an expression containing another sub-select.
    - Fix failure to mark cached plans as transient.
      If a plan is prepared while "CREATE INDEX CONCURRENTLY" is in
      progress for one of the referenced tables, it is supposed to be
      re-planned once the index is ready for use. This was not happening
      reliably.
    - Reduce PANIC to ERROR in some occasionally-reported btree failure
      cases, and provide additional detail in the resulting error
      messages.
      This should improve the system's robustness with corrupted indexes.
    - Prevent show_session_authorization() from crashing within
      autovacuum processes.
    - Defend against functions returning setof record where not all the
      returned rows are actually of the same rowtype.
    - Fix possible failure when hashing a pass-by-reference function
      result.
    - Improve mer...

Read more...

Launchpad Janitor (janitor) wrote :
Download full text (5.8 KiB)

This bug was fixed in the package postgresql-8.3 - 8.3.12-0ubuntu8.04

---------------
postgresql-8.3 (8.3.12-0ubuntu8.04) hardy-security; urgency=low

  * New upstream security/bug fix release: (LP: #655293)
    - Use a separate interpreter for each calling SQL userid in PL/Perl
      and PL/Tcl.
      This change prevents security problems that can be caused by
      subverting Perl or Tcl code that will be executed later in the same
      session under another SQL user identity (for example, within a
      SECURITY DEFINER function). Most scripting languages offer numerous
      ways that that might be done, such as redefining standard functions
      or operators called by the target function. Without this change,
      any SQL user with Perl or Tcl language usage rights can do
      essentially anything with the SQL privileges of the target
      function's owner.
      The cost of this change is that intentional communication among
      Perl and Tcl functions becomes more difficult. To provide an escape
      hatch, PL/PerlU and PL/TclU functions continue to use only one
      interpreter per session. This is not considered a security issue
      since all such functions execute at the trust level of a database
      superuser already.
      It is likely that third-party procedural languages that claim to
      offer trusted execution have similar security issues. We advise
      contacting the authors of any PL you are depending on for
      security-critical purposes.
      Our thanks to Tim Bunce for pointing out this issue
      (CVE-2010-3433).
    - Prevent possible crashes in pg_get_expr() by disallowing it from
      being called with an argument that is not one of the system catalog
      columns it's intended to be used with.
    - Fix incorrect usage of non-strict OR joinclauses in Append
      indexscans.
      This is a back-patch of an 8.4 fix that was missed in the 8.3
      branch. This corrects an error introduced in 8.3.8 that could cause
      incorrect results for outer joins when the inner relation is an
      inheritance tree or UNION ALL subquery.
    - Fix possible duplicate scans of UNION ALL member relations.
    - Fix "cannot handle unplanned sub-select" error.
      This occurred when a sub-select contains a join alias reference
      that expands into an expression containing another sub-select.
    - Fix failure to mark cached plans as transient.
      If a plan is prepared while "CREATE INDEX CONCURRENTLY" is in
      progress for one of the referenced tables, it is supposed to be
      re-planned once the index is ready for use. This was not happening
      reliably.
    - Reduce PANIC to ERROR in some occasionally-reported btree failure
      cases, and provide additional detail in the resulting error
      messages.
      This should improve the system's robustness with corrupted indexes.
    - Prevent show_session_authorization() from crashing within
      autovacuum processes.
    - Defend against functions returning setof record where not all the
      returned rows are actually of the same rowtype.
    - Fix possible failure when hashing a pass-by-reference function
      result.
    - Improve merg...

Read more...

Changed in postgresql-8.3 (Ubuntu Hardy):
status: In Progress → Fix Released
Changed in postgresql-8.3 (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Changed in postgresql-8.4 (Ubuntu Karmic):
status: In Progress → Fix Released
Changed in postgresql-8.4 (Ubuntu Lucid):
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

I suppose dapper was released together with the others (I saw the ACCEPT), but isn't autoclosing.

Changed in postgresql-8.1 (Ubuntu Dapper):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (8.3 KiB)

This bug was fixed in the package postgresql-8.4 - 8.4.5-0ubuntu10.10

---------------
postgresql-8.4 (8.4.5-0ubuntu10.10) maverick-security; urgency=medium

  * New upstream security/bug fix update: (LP: #655293)
    - Use a separate interpreter for each calling SQL userid in PL/Perl
      and PL/Tcl.
      This change prevents security problems that can be caused by
      subverting Perl or Tcl code that will be executed later in the same
      session under another SQL user identity (for example, within a
      SECURITY DEFINER function). Most scripting languages offer numerous
      ways that that might be done, such as redefining standard functions
      or operators called by the target function. Without this change,
      any SQL user with Perl or Tcl language usage rights can do
      essentially anything with the SQL privileges of the target
      function's owner.
      The cost of this change is that intentional communication among
      Perl and Tcl functions becomes more difficult. To provide an escape
      hatch, PL/PerlU and PL/TclU functions continue to use only one
      interpreter per session. This is not considered a security issue
      since all such functions execute at the trust level of a database
      superuser already.
      It is likely that third-party procedural languages that claim to
      offer trusted execution have similar security issues. We advise
      contacting the authors of any PL you are depending on for
      security-critical purposes.
      Our thanks to Tim Bunce for pointing out this issue
      (CVE-2010-3433).
    - Prevent possible crashes in pg_get_expr() by disallowing it from
      being called with an argument that is not one of the system catalog
      columns it's intended to be used with.
    - Fix incorrect placement of placeholder evaluation.
      This bug could result in query outputs being non-null when they
      should be null, in cases where the inner side of an outer join is a
      sub-select with non-strict expressions in its output list.
    - Fix possible duplicate scans of UNION ALL member relations.
    - Fix "cannot handle unplanned sub-select" error.
      This occurred when a sub-select contains a join alias reference
      that expands into an expression containing another sub-select.
    - Fix mishandling of whole-row Vars that reference a view or
      sub-select and appear within a nested sub-select.
    - Fix mishandling of cross-type IN comparisons.
      This could result in failures if the planner tried to implement an
      IN join with a sort-then-unique-then-plain-join plan.
    - Fix computation of "ANALYZE" statistics for tsvector columns.
      The original coding could produce incorrect statistics, leading to
      poor plan choices later.
    - Improve planner's estimate of memory used by array_agg(),
      string_agg(), and similar aggregate functions.
      The previous drastic underestimate could lead to out-of-memory
      failures due to inappropriate choice of a hash-aggregation plan.
    - Fix failure to mark cached plans as transient.
      If a plan is prepared while "CREATE INDEX CONCURRENTLY" is in
      progress for one of the referenced ...

Read more...

Changed in postgresql-8.4 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Changed in postgresql-8.4 (Ubuntu Karmic):
assignee: nobody → Freddy (freddyfernandolobo)
Kees Cook (kees) on 2010-10-20
Changed in postgresql-8.4 (Ubuntu Karmic):
assignee: Freddy (freddyfernandolobo) → nobody
Changed in postgresql-8.4 (Ubuntu):
assignee: Martin Pitt (pitti) → Freddy (freddyfernandolobo)
Steve Langasek (vorlon) on 2010-10-21
Changed in postgresql-8.4 (Ubuntu):
assignee: Freddy (freddyfernandolobo) → Martin Pitt (pitti)
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers