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 security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Prevent deadlock while disabling aRFS

The Linux kernel CVE team has assigned CVE-2024-27014 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T

Accounts. The issue was addressed with improved checks.

Impact

Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request().

Patches

This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75. Fixes has been released in v5.28.4 and v6.11.1.

Workarounds

use fetch() or disable maxRedirections.

References

Linzi Shang reported this.

https://hackerone.com/reports/2408074 https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3

Last updated 24 July 2024

Impact An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.

Patches The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3

The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

A flaw in the Linux Kernel found in the Open vSwitch Kernel module.

The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.

Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.

Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/

All versions of the package angular are vulnerable to Regular Expression Denial of Service (ReDoS) via the $resource service due to the usage of an insecure regular expression. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

All versions of the package angular are vulnerable to Regular Expression Denial of Service (ReDoS) via the <input type="url"> element due to the usage of an insecure regular expression in the input[url] functionality. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

All versions of the package angular are vulnerable to Regular Expression Denial of Service (ReDoS) via the angular.copy() utility function due to the usage of an insecure regular expression. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

A vulnerability was found in Redis. This flaw allows authenticated users to use the HINCRBYFLOAT command to create an invalid hash field that may crash Redis on access.

Summary

A XSS vulnerability exists on index pages for static file handling.

Details

When using web.static(..., showindex=True), the resulting index pages do not escape file names.

If users can upload files with arbitrary filenames to the static directory, the server is vulnerable to XSS attacks.

Workaround

We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected.

Other users can disable showindex if unable to upgrade.

-----

Patch: https://github.com/aio-libs/aiohttp/pull/8319/files

Impact I found "multipart/form-data request tampering vulnerability" caused by Content-Disposition "filename" lack of escaping in httparty.

httparty/lib/httparty/request > body.rb > def generatemultipart

https://github.com/jnunemaker/httparty/blob/4416141d37fd71bdba4f37589ec265f55aa446ce/lib/httparty/request/body.rb#L43

By exploiting this problem, the following attacks are possible

An attack that rewrites the "name" field according to the crafted file name, impersonating (overwriting) another field. Attacks that rewrite the filename extension at the time multipart/form-data is generated by tampering with the filename

For example, this vulnerability can be exploited to generate the following Content-Disposition.

Normal Request example: normal input filename: abc.txt generated normal header in multipart/form-data Content-Disposition: form-data; name="avatar"; filename="abc.txt" Malicious Request example malicious input filename: overwritenamefieldandextension.sh"; name="foo"; dummy=".txt generated malicious header in multipart/form-data: Content-Disposition: form-data; name="avatar"; filename="overwritenamefieldandextension.sh"; name="foo"; dummy=".txt"

The Abused Header has multiple name ( avatar & foo ) fields and the "filename" has been rewritten from .txt to .sh .

These problems can result in successful or unsuccessful attacks, depending on the behavior of the parser receiving the request. I have confirmed that the attack succeeds, at least in the following frameworks

Spring (Java) Ktor (Kotlin) Ruby on Rails (Ruby)

The cause of this problem is the lack of escaping of the " (Double-Quote) character in Content-Disposition > filename.

WhatWG's HTML spec has an escaping requirement.

https://html.spec.whatwg.org/#multipart-form-data

For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence %0A, 0x0D (CR) with %0D and 0x22 (") with %22. The user agent must not perform any other escapes.

Patches

As noted at the beginning of this section, encoding must be done as described in the HTML Spec.

https://html.spec.whatwg.org/#multipart-form-data

For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence %0A, 0x0D (CR) with %0D and 0x22 (") with %22. The user agent must not perform any other escapes.

Therefore, it is recommended that Content-Disposition be modified by either of the following

Before: Content-Disposition: attachment;filename="malicious.sh";dummy=.txt

After: Content-Disposition: attachment;filename="%22malicious.sh%22;dummy=.txt"

https://github.com/jnunemaker/httparty/blob/4416141d37fd71bdba4f37589ec265f55aa446ce/lib/httparty/request/body.rb#L43

filename.gsub('"', '%22')

Also, as for \r, \n, URL Encode is not done, but it is not newlines, so it seemed to be OK. However, since there may be omissions, it is safer to URL encode these as well, if possible. ( \r to %0A and \d to %0D )

PoC

PoC Environment

OS: macOS Monterey(12.3) Ruby ver: ruby 3.1.2p20 httparty ver: 0.20.0 (Python3 - HTTP Request Logging Server)

PoC procedure

(Linux or MacOS is required. This is because Windows does not allow file names containing " (double-quote) .)

1. Create Project $ mkdir my-app $ cd my-app $ gem install httparty

2. Create malicious file

$ touch 'overwritenamefieldandextension.sh"; name="foo"; dummy=".txt'

3. Generate Vuln code

$ vi example.rb

require 'httparty'

filename = 'overwritenamefieldandextension.sh"; name="foo"; dummy=".txt'

HTTParty.post('http://localhost:12345/', body: { name: 'Foo Bar', email: 'example@email.com', avatar: File.open(filename) } )

4. Run Logging Server

I write Python code, but any method will work as long as you can see the HTTP Request Body. (e.g. Debugger, HTTP Logging Server, Packet Capture)

$ vi logging.py from http.server import HTTPServer from http.server import BaseHTTPRequestHandler

class LoggingServer(BaseHTTPRequestHandler):

def doPOST(self): self.sendresponse(200) self.endheaders() self.wfile.write("ok".encode("utf-8"))

contentlength = int(self.headers['Content-Length']) postdata = self.rfile.read(contentlength) print("POST request,\nPath: %s\nHeaders:\n%s\n\nBody:\n%s\n", str(self.path), str(self.headers), postdata.decode('utf-8')) self.wfile.write("POST request for {}".format(self.path).encode('utf-8'))

ip = '127.0.0.1' port = 12345

server = HTTPServer((ip, port), LoggingServer) server.serveforever()

$ python logging.py

5. Run & Logging server

$ run example.rb

Return Request Header & Body:

User-Agent: Ruby Content-Type: multipart/form-data; boundary=------------------------F857UcxRc2J1zFOz Connection: close Host: localhost:12345 Content-Length: 457 --------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="name" Foo Bar --------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="email" example@email.com --------------------------F857UcxRc2J1zFOz Content-Disposition: form-data; name="avatar"; filename="overwritenamefieldandextension.sh"; name="foo"; dummy=".txt" Content-Type: text/plain abc --------------------------F857UcxRc2J1zFOz--

Content-Disposition: Content-Disposition: form-data; name="avatar"; filename="overwritenamefieldandextension.sh"; name="foo"; dummy=".txt"

name fields is duplicate (avator & foo) filename & extension tampering ( .txt --> .sh )

References

1. I also include a similar report that I previously reported to Firefox. https://bugzilla.mozilla.org/showbug.cgi?id=1556711

2. I will post some examples of frameworks that did not have problems as reference.

Golang https://github.com/golang/go/blob/e0e0c8fe9881bbbfe689ad94ca5dddbb252e4233/src/mime/multipart/writer.go#L144

Spring https://github.com/spring-projects/spring-framework/blob/4cc91e46b210b4e4e7ed182f93994511391b54ed/spring-web/src/main/java/org/springframework/http/ContentDisposition.java#L259-L267

Symphony https://github.com/symfony/symfony/blob/123b1651c4a7e219ba59074441badfac65525efe/src/Symfony/Component/Mime/Header/ParameterizedHeader.php#L128-L133

For more information If you have any questions or comments about this advisory: Email us at kumagoroalice@yahoo.co.jp

A flaw has been identified in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the nssgethostbyname2r and nssgetcanonnamer hooks without implementing the nssgethostbyname3r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AFINET6 address family with AICANONNAME, AIALL and AIV4MAPPED as flags.

Last updated 24 July 2024

A flaw was found in glibc. When the getaddrinfo function is called with the AFUNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash.

A flaw found in the urllib3. The urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like POST) to GET as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with redirects=False and disable automatic redirects with redirects=False and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

References: https://github.com/urllib3/urllib3/security/advisories/GHSA-g4mx-q9vg-27p4 https://www.rfc-editor.org/rfc/rfc9110.html#name-get https://github.com/urllib3/urllib3/commit/4e98d57809dacab1cbe625fddeec1a290c478ea9

Accessibility. A logging issue was addressed with improved data redaction.

A use-after-free flaw was found in the xorg-x11-server. An X server crash may occur in a very specific and legacy configuration (a multi-screen setup with multiple protocol screens, also known as Zaphod mode) if the pointer is warped from within a window on one screen to the root window of the other screen and if the original window is destroyed followed by another window being destroyed.

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

A buffer overflow flaw was found in base/gdevdevn.c:1973 in devnpcxwriterle() in ghostscript. This issue may allow a local attacker to cause a denial of service via outputting a crafted PDF file for a DEVN device with gs.

Chromium: CVE-2024-4950 Inappropriate implementation in Downloads