#postgres

Ubuntu Security Notice 5571-1 - Sven Klemm discovered that PostgreSQL incorrectly handled extensions. An attacker could possibly use this issue to execute arbitrary code when extensions are created or updated.

A vulnerability found in postgresql. On this security issue an attack requires permission to create non-temporary objects in at least one schema, ability to lure or wait for an administrator to create or update an affected extension in that schema, and ability to lure or wait for a victim to use the object targeted in CREATE OR REPLACE or CREATE IF NOT EXISTS. Given all three prerequisites, the attacker can run arbitrary code as the victim role, which may be a superuser. Known-affected extensions include both PostgreSQL-bundled and non-bundled extensions. PostgreSQL blocks this attack in the core server, so there's no need to modify individual extensions.

Flaws discovered in various PostgreSQL-as-a-Service offerings, including those from Microsoft and Google

Directory Traversal vulnerability ZDBQAREFSUBDIR parameter in /zropusermgmt API in Zoho ManageEngine Analytics Plus before 4350 allows remote attackers to run arbitrary code.

Improper input validation on the `contains` LoopBack filter may allow for arbitrary SQL injection. When the extended filter property `contains` is permitted to be interpreted by the Postgres connector, it is possible to inject arbitrary SQL which may affect the confidentiality and integrity of data stored on the connected database. A patch was released in version 5.5.1. This affects users who does any of the following: - Connect to the database via the DataSource with `allowExtendedProperties: true` setting OR - Uses the connector's CRUD methods directly OR - Uses the connector's other methods to interpret the LoopBack filter. Users who are unable to upgrade should do the following if applicable: - Remove `allowExtendedProperties: true` DataSource setting - Add `allowExtendedProperties: false` DataSource setting - When passing directly to the connector functions, manually sanitize the user input for the `contains` LoopBack filter beforehand.

An issue was discovered in the YugabyteDB 2.6.1 when using LDAP-based authentication in YCQL with Microsoft’s Active Directory. When anonymous or unauthenticated LDAP binding is enabled, it allows bypass of authentication with an empty password.

Improper input validation on the `contains` LoopBack filter may allow for arbitrary SQL injection. ### Impact When the extended filter property `contains` is permitted to be interpreted by the Postgres connector, it is possible to inject arbitrary SQL which may affect the confidentiality and integrity of data stored on the connected database. This affects users who does any of the following: - Connect to the database via the DataSource with `allowExtendedProperties: true` setting OR - Uses the connector's CRUD methods directly OR - Uses the connector's other methods to interpret the LoopBack filter. ### Patches Patch release `[email protected]` has been published of which resolves this issue. ### Workarounds Users who are unable to upgrade should do the following if applicable: - Remove `allowExtendedProperties: true` DataSource setting - Add `allowExtendedProperties: false` DataSource setting - When passing directly to the connector functions, manually sanit...

### Impact _What kind of vulnerability is it? Who is impacted?_ The PGJDBC implementation of the `java.sql.ResultRow.refreshRow()` method is not performing escaping of column names so a malicious column name that contains a statement terminator, e.g. `;`, could lead to SQL injection. This could lead to executing additional SQL commands as the application's JDBC user. User applications that do not invoke the `ResultSet.refreshRow()` method are not impacted. User application that do invoke that method are impacted if the underlying database that they are querying via their JDBC application may be under the control of an attacker. The attack requires the attacker to trick the user into executing SQL against a table name who's column names would contain the malicious SQL and subsequently invoke the `refreshRow()` method on the ResultSet. For example: ```sql CREATE TABLE refresh_row_example ( id int PRIMARY KEY, "1 FROM refresh_row_example; SELECT pg_sleep(10); SELECT * " int )...

PostgreSQL JDBC Driver (PgJDBC for short) allows Java programs to connect to a PostgreSQL database using standard, database independent Java code. The PGJDBC implementation of the `java.sql.ResultRow.refreshRow()` method is not performing escaping of column names so a malicious column name that contains a statement terminator, e.g. `;`, could lead to SQL injection. This could lead to executing additional SQL commands as the application's JDBC user. User applications that do not invoke the `ResultSet.refreshRow()` method are not impacted. User application that do invoke that method are impacted if the underlying database that they are querying via their JDBC application may be under the control of an attacker. The attack requires the attacker to trick the user into executing SQL against a table name who's column names would contain the malicious SQL and subsequently invoke the `refreshRow()` method on the ResultSet. Note that the application's JDBC user and the schema owner need not be ...

This affects all versions of package heroku-env. The injection point is located in lib/get.js which is required by index.js.