CVE-2010-1170: Medium severity PostgreSQL postgresql vulnerability
A flaw was found in the way the PostgreSQL enforced permission checks on scripts written in PL/Tcl. Once the PL/Tcl procedural language was registered on particular database, a remote, authenticated user, privileged to create databases, running a specially-crafted PL/Tcl script, could use this flaw to bypass intended PL/Tcl trusted mode restrictions, allowing them to run arbitrary Tcl scripts with the privileges of the database server.
References: [1] PostgreSQL PL/Tcl procedural language manual page: http://www.postgresql.org/docs/8.1/interactive/pltcl.html
Other sources
The PL/Tcl implementation in PostgreSQL 7.4 before 7.4.29, 8.0 before 8.0.25, 8.1 before 8.1.21, 8.2 before 8.2.17, 8.3 before 8.3.11, 8.4 before 8.4.4, and 9.0 Beta before 9.0 Beta 2 loads Tcl code from the pltclmodules table regardless of the table's ownership and permissions, which allows remote authenticated users, with database-creation privileges, to execute arbitrary Tcl code by creating this table and inserting a crafted Tcl script.
— Red Hat
Affected Software
Remediation
Patch Available
Event History
Parent advisories
This vulnerability appears in the following advisories.
Frequently Asked Questions
What is the severity of CVE-2010-1170?
CVE-2010-1170 has a severity rating classified as medium due to its potential to allow unauthorized security access.
How do I fix CVE-2010-1170?
To fix CVE-2010-1170, upgrade your PostgreSQL version to at least 7.4.29, 8.0.25, 8.1.21, or 8.2.17.
Which PostgreSQL versions are affected by CVE-2010-1170?
CVE-2010-1170 affects PostgreSQL versions 7.4 prior to 7.4.29, 8.0 prior to 8.0.25, 8.1 prior to 8.1.21, 8.2 prior to 8.2.17, 8.3 prior to 8.3.11, 8.4 prior to 8.4.4, and 9.0 Beta before 9.0 Beta 2.
What type of attack can exploit CVE-2010-1170?
CVE-2010-1170 can be exploited to load Tcl code from the pltcl_modules table, which could lead to remote code execution.
Is there a workaround for CVE-2010-1170 if I cannot upgrade?
If upgrading is not an option, you can restrict access to the pltcl_modules table and ensure proper permission settings to mitigate the risk.