CVE-2023-2454: CREATE SCHEMA ... schemaelement defeats protective searchpath changes.
Versions Affected: 11 - 15. This problem is quite old.
This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.
https://www.postgresql.org/support/security/CVE-2023-2454/
CVE-2023-2455: Row security policies disregard user ID changes after inlining.
Versions Affected: 11 - 15. This problem is quite old.
While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.
https://www.postgresql.org/support/security/CVE-2023-2455/
A crafted request uri-path can cause modproxy to forward the request to an origin server choosen by the remote user. This issue affects Apache HTTP Server 2.4.48 and earlier.
A flaw was found in PostgreSQL's "ALTER ... DEPENDS ON EXTENSION", where sub-commands did not perform authorization checks. An authenticated attacker could use this flaw in certain configurations to perform drop objects such as function, triggers, et al., leading to database corruption.
A flaw was found in postgresql in versions before 13.3, before 12.7, before 11.12, before 10.17 and before 9.6.22. While modifying certain SQL array values, missing bounds checks let authenticated database users write arbitrary bytes to a wide area of server memory. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A flaw was found in HTTP/2. Using SETTINGS frames and queuing of SETTINGS ACK frames, a flood could occur resulting in unbounded memory growth. The highest threat from this vulnerability is to system availability.
A flaw was found in HTTP/2. An attacker, using PRIORITY frames to flood the system, could cause excessive CPU usage and starvation of other clients. The largest threat from this vulnerability is to system availability.
A flaw was found in HTTP/2. An attacker, sending a stream of header with a 0-length header name and a 0-length header value, could cause some implementations to allocate memory for these headers and keep the allocations alive until the session dies. The can consume excess memory, potentially leading to a denial of service. The highest threat from this vulnerability is to system availability.
A vulnerability was found in http/2 where an attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
A user having some UPDATE privilege on a partitioned table but lacking the SELECT privilege on some column may nonetheless be able to acquire denied-column values from an error message. This is similar to CVE-2014-8161, but the conditions for exploitation are more rare.
The PostgreSQL project thanks Heikki Linnakangas for reporting this problem.
A flaw was found in redis. When using the Redis Lua Debugger, users can send malformed requests that cause the debugger’s protocol parser to read data beyond the actual buffer, potentially leading to an information disclosure.
A memory disclosure vulnerability was found in PostgreSQL that allows remote users to access sensitive information by exploiting certain aggregate function calls with 'unknown'-type arguments. Handling 'unknown'-type values from string literals without type designation can disclose bytes, potentially revealing notable and confidential information. This issue exists due to excessive data output in aggregate function calls, enabling remote users to read some portion of system memory.
A flaw was found in Python 3's pydoc. This flaw allows a local or adjacent attacker who discovers or can convince another local or adjacent user to start a pydoc server to access the server and then use it to disclose sensitive information belonging to the other user that they would not normally have the ability to access. The highest threat from this vulnerability is to data confidentiality.
Apache HTTP Server versions 2.4.20 to 2.4.43. A specially crafted value for the 'Cache-Digest' header in a HTTP/2 request would result in a crash when the server actually tries to HTTP/2 PUSH a resource afterwards. Configuring the HTTP/2 feature via "H2Push off" will mitigate this vulnerability for unpatched servers.
File Content Disclosure in Action View
Impact ------ There is a possible file content disclosure vulnerability in Action View. Specially crafted accept headers in combination with calls to render file: can cause arbitrary files on the target server to be rendered, disclosing the file contents.
The impact is limited to calls to render which render file contents without a specified accept format. Impacted code in a controller looks something like this:
ruby class UserController < ApplicationController def index render file: "#{Rails.root}/some/file" end end
Rendering templates as opposed to files is not impacted by this vulnerability.
All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases -------- The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are available at the normal locations.
Workarounds ----------- This vulnerability can be mitigated by specifying a format for file rendering, like this:
ruby class UserController < ApplicationController def index render file: "#{Rails.root}/some/file", formats: [:html] end end
In summary, impacted calls to render look like this:
render file: "#{Rails.root}/some/file"
The vulnerability can be mitigated by changing to this:
render file: "#{Rails.root}/some/file", formats: [:html]
Other calls to render are not impacted.
Alternatively, the following monkey patch can be applied in an initializer:
ruby $ cat config/initializers/formatsfilter.rb frozenstringliteral: true
ActionDispatch::Request.prepend(Module.new do def formats super().select do |format| format.symbol || format.ref == "/" end end end)
Credits ------- Thanks to John Hawthorn <john@hawthorn.email> of GitHub
Fixed bug (Out-of-bounds read in iconv.c:phpiconvmimedecode() due to integer overflow) (CVE-2019-11039).
Fixed bug (heap-buffer-overflow on phpjpgget16) (CVE-2019-11040).
apachemodphp. Multiple issues were addressed by updating to PHP version 7.3.11.
Fixed bug (Heap-buffer-overflow in estrndup via exifprocessIFDTAG) (CVE-2019-11036).
In Pallets Jinja before 2.10.1, str.formatmap allows a sandbox escape.
The sandbox is used to restrict what code can be evaluated when rendering untrusted, user-provided templates. Due to the way string formatting works in Python, the str.formatmap method could be used to escape the sandbox.
This issue was previously addressed for the str.format method in Jinja 2.8.1, which discusses the issue in detail. However, the less-common str.formatmap method was overlooked. This release applies the same sandboxing to both methods.
If you cannot upgrade Jinja, you can override the issafeattribute method on the sandbox and explicitly disallow the formatmap method on string objects.
Apache HTTP Server, with MPM event, worker or prefork, code executing in less-privileged child processes or threads (including scripts executed by an in-process scripting interpreter) could execute code with the privileges of the parent process (usually root) by manipulating the scoreboard.
Directory traversal vulnerability in Action View in Ruby on Rails allows remote attackers to read arbitrary files.
An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.
Supported, Vulnerable Versions: 11 - 15.
A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server's memory.
A flaw was found in PostgreSQL involving the pgcancelbackend role that signals background workers, including the logical replication launcher, autovacuum workers, and the autovacuum launcher. Successful exploitation requires a non-core extension with a less-resilient background worker and would affect that specific background worker only. This issue may allow a remote high privileged user to launch a denial of service (DoS) attack.
A flaw was found in the Java logging library Apache Log4j in version 1.x . This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender.
In 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
This flaw in Log4j 2.x is tracked via CVE-2021-44228
A flaw was found in Ruby. RubyGems cgi gem could allow a remote attacker to conduct spoofing attacks caused by the mishandling of security prefixes in cookie names in the CGI::Cookie.parse function. By sending a specially-crafted request, an attacker could perform cookie prefix spoofing attacks.
A flaw was found in HTTP/2. Using frames with an empty payload, a flood could occur that results in excessive CPU usage and starvation of other clients. The highest threat from this vulnerability is to system availability.
APR. Multiple issues in Perl were addressed with improved memory handling.
A flaw was found in HTTP/2. Using HEADER frames with invalid HTTP headers and queuing of response RSTSTREAM frames, an attacker could cause a flood resulting in unbounded memory growth. The highest threat from this vulnerability is to system availability.