Уязвимость текстового поля для ввода пароля менеджера паролей KeePass, связанная с хранением учетных данных в незашифрованном виде, позволяющая нарушителю восстановить мастер-пароль в открытом виде

Уязвимость менеджера паролей KeePass, связанная с незашифрованным хранением критичной информации, позволяющая нарушителю получить пароли в открытом виде

KeePass through 2.53 (in a default installation) allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger. NOTE: the vendor's position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.

In KeePass 2.x before 2.54, it is possible to recover the cleartext master password from a memory dump, even when a workspace is locked or no longer running. The memory dump can be a KeePass process dump, swap file (pagefile.sys), hibernation file (hiberfil.sys), or RAM dump of the entire system. The first character cannot be recovered. In 2.54, there is different API usage and/or random string insertion for mitigation.

Buffer overflow in the thread scheduler in Chicken before 4.8.0.1 allows attackers to cause a denial of service (crash) by opening a file descriptor with a large integer value.

Chicken before 4.8.0 does not properly handle NUL bytes in certain strings, which allows an attacker to conduct "poisoned NUL byte attack."

A casting error in Chicken before 4.8.0 on 64-bit platform caused the random number generator to return a constant value. NOTE: the vendor states "This function wasn't used for security purposes (and is advertised as being unsuitable)."

Chicken before 4.8.0 is susceptible to algorithmic complexity attacks related to hash table collisions.

Untrusted search path vulnerability in csi in Chicken before 4.8.2 allows local users to execute arbitrary code via a Trojan horse .csirc in the current working directory.

OS command injection vulnerability in the "qs" procedure from the "utils" module in Chicken before 4.9.0.

Multiple buffer overflows in the (1) R5RS char-ready, (2) tcp-accept-ready, and (3) file-select procedures in Chicken through 4.8.0.3 allows attackers to cause a denial of service (crash) by opening a file descriptor with a large integer value. NOTE: this issue exists because of an incomplete fix for CVE-2012-6122.

Buffer overflow in the "read-string!" procedure in the "extras" unit in CHICKEN stable before 4.8.0.5 and development snapshots before 4.8.3 allows remote attackers to cause a denial of service (memory corruption and application crash) and possibly execute arbitrary code via a "#f" value in the NUM argument.

Buffer overflow in the "read-u8vector!" procedure in the srfi-4 unit in CHICKEN stable 4.8.0.7 and development snapshots before 4.9.1 allows remote attackers to cause a denial of service (memory corruption and application crash) and possibly execute arbitrary code via a "#f" value in the NUM argument.

The string-translate* procedure in the data-structures unit in CHICKEN before 4.10.0 allows remote attackers to cause a denial of service (crash).

The "process-execute" and "process-spawn" procedures in CHICKEN Scheme used fixed-size buffers for holding the arguments and environment variables to use in its execve() call. This would allow user-supplied argument/environment variable lists to trigger a buffer overrun. This affects all releases of CHICKEN up to and including 4.11 (it will be fixed in 4.12 and 5.0, which are not yet released).

The "process-execute" and "process-spawn" procedures did not free memory correctly when the execve() call failed, resulting in a memory leak. This could be abused by an attacker to cause resource exhaustion or a denial of service. This affects all releases of CHICKEN up to and including 4.11 (it will be fixed in 4.12 and 5.0, which are not yet released).

Due to an incomplete fix for CVE-2012-6125, all versions of CHICKEN Scheme up to and including 4.12.0 are vulnerable to an algorithmic complexity attack. An attacker can provide crafted input which, when inserted into the symbol table, will result in O(n) lookup time.

An incorrect "pair?" check in the Scheme "length" procedure results in an unsafe pointer dereference in all CHICKEN Scheme versions prior to 4.13, which allows an attacker to cause a denial of service by passing an improper list to an application that calls "length" on it.

6.12.0

mono FTBFS

Обновление mono до версии 6.12.0.182.

Уязвимость переменных среды PL/Perl системы управления базами данных PostgreSQL, позволяющая нарушителю выполнить произвольный код

Уязвимость команд SET ROLE, SET SESSION системы управления базами данных PostgreSQL, позволяющая нарушителю повысить свои привилегии и получить доступ к защищаемой информации

Уязвимость компонента libpq системы управления базами данных PostgreSQL, позволяющая нарушителю обойти существующие ограничения безопасности и выполнить атаку типа «человек посередине»

Уязвимость политики безопасности таблиц с защитой строк CREATE POLICY системы управления базами данных PostgreSQL, позволяющая нарушителю выполнить произвольные команды

Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended. CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes. They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. This has the same consequences as the two earlier CVEs. That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy. An attacker must tailor an attack to a particular application's pattern of query plan reuse, user ID changes, and role-specific row security policies. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts to current_setting('role') or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Уязвимость переменных среды PL/Perl системы управления базами данных PostgreSQL, позволяющая нарушителю выполнить произвольный код

Уязвимость команд SET ROLE, SET SESSION системы управления базами данных PostgreSQL, позволяющая нарушителю повысить свои привилегии и получить доступ к защищаемой информации

Уязвимость компонента libpq системы управления базами данных PostgreSQL, позволяющая нарушителю обойти существующие ограничения безопасности и выполнить атаку типа «человек посередине»

Уязвимость политики безопасности таблиц с защитой строк CREATE POLICY системы управления базами данных PostgreSQL, позволяющая нарушителю выполнить произвольные команды

Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended. CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes. They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. This has the same consequences as the two earlier CVEs. That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy. An attacker must tailor an attack to a particular application's pattern of query plan reuse, user ID changes, and role-specific row security policies. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts to current_setting('role') or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.