FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The last vuln.xml file processed by FreshPorts is:

Revision:  368515
Date:      2014-09-18
Time:      19:53:09Z
Committer: madpilot

List all Vulnerabilities, by package

List all Vulnerabilities, by date

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
51436b4c-1250-11dd-bab7-0016179b2dd5postgresql -- multiple vulnerabilities

The PostgreSQL developers report:

PostgreSQL allows users to create indexes on the results of user-defined functions, known as "expression indexes". This provided two vulnerabilities to privilege escalation: (1) index functions were executed as the superuser and not the table owner during VACUUM and ANALYZE, and (2) that SET ROLE and SET SESSION AUTHORIZATION were permitted within index functions. Both of these holes have now been closed.

PostgreSQL allowed malicious users to initiate a denial-of-service by passing certain regular expressions in SQL queries. First, users could create infinite loops using some specific regular expressions. Second, certain complex regular expressions could consume excessive amounts of memory. Third, out-of-range backref numbers could be used to crash the backend.

DBLink functions combined with local trust or ident authentication could be used by a malicious user to gain superuser privileges. This issue has been fixed, and does not affect users who have not installed DBLink (an optional module), or who are using password authentication for local access. This same problem was addressed in the previous release cycle, but that patch failed to close all forms of the loophole.


Discovery 2008-01-06
Entry 2008-04-24
postgresql
postgresql-server
ge 7.3 lt 7.3.21

ge 7.4 lt 7.4.19

ge 8.0 lt 8.0.15

ge 8.1 lt 8.1.11

ge 8.2 lt 8.2.6

CVE-2007-6600
CVE-2007-4772
CVE-2007-6067
CVE-2007-4769
CVE-2007-6601
27163
http://www.postgresql.org/about/news.905
17f53c1d-2ae9-11db-a6e2-000e0c2e438apostgresql -- encoding based SQL injection

The PostgreSQL development team reports:

An attacker able to submit crafted strings to an application that will embed those strings in SQL commands can use invalidly-encoded multibyte characters to bypass standard string-escaping methods, resulting in possible injection of hostile SQL commands into the database. The attacks covered here work in any multibyte encoding.

The widely-used practice of escaping ASCII single quote "'" by turning it into "\'" is unsafe when operating in multibyte encodings that allow 0x5c (ASCII code for backslash) as the trailing byte of a multibyte character; this includes at least SJIS, BIG5, GBK, GB18030, and UHC. An application that uses this conversion while embedding untrusted strings in SQL commands is vulnerable to SQL-injection attacks if it communicates with the server in one of these encodings. While the standard client libraries used with PostgreSQL have escaped "'" in the safe, SQL-standard way of "''" for some time, the older practice remains common.


Discovery 2006-05-11
Entry 2006-08-13
postgresql
postgresql-server
ja-postgresql
ge 7.3 lt 7.3.15

ge 7.4 lt 7.4.13

ge 8.0.0 lt 8.0.8

ge 8.1.0 lt 8.1.4

18092
CVE-2006-2313
CVE-2006-2314
http://www.postgresql.org/docs/techdocs.50
51436b4c-1250-11dd-bab7-0016179b2dd5postgresql -- multiple vulnerabilities

The PostgreSQL developers report:

PostgreSQL allows users to create indexes on the results of user-defined functions, known as "expression indexes". This provided two vulnerabilities to privilege escalation: (1) index functions were executed as the superuser and not the table owner during VACUUM and ANALYZE, and (2) that SET ROLE and SET SESSION AUTHORIZATION were permitted within index functions. Both of these holes have now been closed.

PostgreSQL allowed malicious users to initiate a denial-of-service by passing certain regular expressions in SQL queries. First, users could create infinite loops using some specific regular expressions. Second, certain complex regular expressions could consume excessive amounts of memory. Third, out-of-range backref numbers could be used to crash the backend.

DBLink functions combined with local trust or ident authentication could be used by a malicious user to gain superuser privileges. This issue has been fixed, and does not affect users who have not installed DBLink (an optional module), or who are using password authentication for local access. This same problem was addressed in the previous release cycle, but that patch failed to close all forms of the loophole.


Discovery 2008-01-06
Entry 2008-04-24
postgresql
postgresql-server
ge 7.3 lt 7.3.21

ge 7.4 lt 7.4.19

ge 8.0 lt 8.0.15

ge 8.1 lt 8.1.11

ge 8.2 lt 8.2.6

CVE-2007-6600
CVE-2007-4772
CVE-2007-6067
CVE-2007-4769
CVE-2007-6601
27163
http://www.postgresql.org/about/news.905
17f53c1d-2ae9-11db-a6e2-000e0c2e438apostgresql -- encoding based SQL injection

The PostgreSQL development team reports:

An attacker able to submit crafted strings to an application that will embed those strings in SQL commands can use invalidly-encoded multibyte characters to bypass standard string-escaping methods, resulting in possible injection of hostile SQL commands into the database. The attacks covered here work in any multibyte encoding.

The widely-used practice of escaping ASCII single quote "'" by turning it into "\'" is unsafe when operating in multibyte encodings that allow 0x5c (ASCII code for backslash) as the trailing byte of a multibyte character; this includes at least SJIS, BIG5, GBK, GB18030, and UHC. An application that uses this conversion while embedding untrusted strings in SQL commands is vulnerable to SQL-injection attacks if it communicates with the server in one of these encodings. While the standard client libraries used with PostgreSQL have escaped "'" in the safe, SQL-standard way of "''" for some time, the older practice remains common.


Discovery 2006-05-11
Entry 2006-08-13
postgresql
postgresql-server
ja-postgresql
ge 7.3 lt 7.3.15

ge 7.4 lt 7.4.13

ge 8.0.0 lt 8.0.8

ge 8.1.0 lt 8.1.4

18092
CVE-2006-2313
CVE-2006-2314
http://www.postgresql.org/docs/techdocs.50