A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.

An out of bounds (OOB) memory access flaw was found in the Linux kernel in relayfilereadstartpos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

crypto: algifaead - Revert to operating out-of-place

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

ext/openssl: Memory corruption in opensslencrypt with AES-WRAP-PAD

A vulnerability was found in Ghostscript. This flaw occurs due to a mishandled permission validation for pipe devices (with the %pipe% prefix or the | pipe character prefix).

In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.

A use-after-free vulnerability in the Linux kernel's afunix component can be exploited to achieve local privilege escalation.

The unixstreamsendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unixstreamsendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.

We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c.

EmailValidator and URLValidator were subject to potential regular expression denial of service attack via a very large number of domain name labels of emails and URLs.

Affected versions: Django main development branch, Django 4.2, Django 4.1, Django 3.2

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

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

netsched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.

The patch only checks the cl->clnactive field to determine whether it is the first insertion or not [2], but this field is only incremented by initvf [3].

By using HFSCRSC (which uses inited) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfscdequeue for the reasons we already explained in this report [5].

However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfscenqueue whether the class is already in the eltree whenever the HFSCRSC flag is set.

[1] <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547">https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547</a> [2] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1572</a> [3] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L677</a> [4] <a href="https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574">https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/schhfsc.c#L1574</a> [5] <a href="https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis0G7VEk=@willsroot.io/T/#u">https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigReIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis0G7VEk=@willsroot.io/T/#u</a>

If a Jetty OpenIdAuthenticator uses the optional nested LoginService, and that LoginService decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated.

So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the LoginService.

Impact This impacts usages of the jetty-openid which have configured a nested LoginService and where that LoginService will is capable of rejecting previously authenticated users.

Original Report working on a custom OpenIdAuthenticator, I discovered the following: https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505 In the case where the LoginService does return that the authentication has been revoked (from the validate() call on line 463), the OpenIdAuthenticator removes the authentication from the session; however the current request still proceeds as if authenticated, since it falls through to "return authentication" on line 505. This is fixed by moving the line 505 (and associated debug log) inside the else block that ends on line 502, instead of outside it. Then the revocation case will run through to line 517 and will trigger a new OpenId authentication which I think is correct. I think this revocation can only occur if you do attach a separate LoginService to the OpenIdLoginService, but in that case the revoked authentication will still let the next request through (and possibly more than one if they are very close to simultaneous). Technically I think this is a security vulnerability, if a very minor one, so I'm sending this off-list.

Patched Versions

Fixed in Jetty Versions: 9.4.52 - fixed in PR https://github.com/eclipse/jetty.project/pull/9660 10.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 11.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 12.0.0 - not impacted (already has fix)

Workaround Upgrade your version of Jetty.

References https://github.com/eclipse/jetty.project/pull/9528 https://github.com/eclipse/jetty.project/pull/9660

An integer overflow in MetaDataBuilder.checkSize allows for HTTP/2 HPACK header values to exceed their size limit.

In MetaDataBuilder.java, the following code determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded:

java 291 public void checkSize(int length, boolean huffman) throws SessionException 292 { 293 // Apply a huffman fudge factor 294 if (huffman) 295 length = (length 4) / 3; 296 if ((size + length) > maxSize) 297 throw new HpackException.SessionException("Header too large %d > %d", size + length, maxSize); 298 }

However, when length is very large and huffman is true, the multiplication by 4 in line 295 will overflow, and length will become negative. (size+length) will now be negative, and the check on line 296 will not be triggered.

Furthermore, MetaDataBuilder.checkSize allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2.

In MetaDataBuilder.java, the following code determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded:

java public void checkSize(int length, boolean huffman) throws SessionException { // Apply a huffman fudge factor if (huffman) length = (length 4) / 3; if ((size + length) > maxSize) throw new HpackException.SessionException("Header too large %d > %d", size + length, maxSize); }

However, no exception is thrown in the case of a negative size. Later, in Huffman.decode, the user-entered length is multiplied by 2 before allocating a buffer:

java public static String decode(ByteBuffer buffer, int length) throws HpackException.CompressionException { Utf8StringBuilder utf8 = new Utf8StringBuilder(length 2); // ...

This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server.

Exploit Scenario 1 An attacker repeatedly sends HTTP messages with the HPACK header 0x00ffffffffff02. Each time this header is decoded: + HpackDecode.decode will determine that a Huffman-coded value of length 805306494 needs to be decoded. + MetaDataBuilder.checkSize will approve this length. + Huffman.decode will allocate a 1.6 GB string array. + Huffman.decode will have a buffer overflow error, and the array will be deallocated the next time garbage collection happens. (Note: this can be delayed by appending valid huffman-coded characters to the end of the header.)

Depending on the timing of garbage collection, the number of threads, and the amount of memory available on the server, this may cause the server to run out of memory.

Exploit Scenario 2 An attacker repeatedly sends HTTP messages with the HPACK header 0x00ff8080ffff0b. Each time this header is decoded: + HpackDecode.decode will determine that a Huffman-coded value of length -1073758081 needs to be decoded + MetaDataBuilder.checkSize will approve this length + The number will be multiplied by 2 to get 2147451134, and Huffman.decode will allocate a 2.1 GB string array + Huffman.decode will have a buffer overflow error, and the array will be deallocated the next time garbage collection happens (Note that this deallocation can be delayed by adding valid Huffman-coded characters to the end of the header)

Depending on the timing of garbage collection, the number of threads, and the amount of memory available on the server, this may cause the server to run out of memory.

Impact Users of HTTP/2 can be impacted by a remote denial of service attack.

Patches Fixed in Jetty 10.0.16 and Jetty 11.0.16 Fixed in Jetty 9.4.53 Jetty 12.x is unaffected.

Workarounds No workarounds possible, only patched versions of Jetty.

References https://github.com/eclipse/jetty.project/pull/9634

The fix for CVE-2023-24998 was incomplete for Apache Tomcat 11.0.0-M2 to 11.0.0-M4, 10.1.5 to 10.1.7, 9.0.71 to 9.0.73 and 8.5.85 to 8.5.87. If non-default HTTP connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur.

Incorrect cipher key & IV length processing

Impact

Jetty accepts the '+' character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response.

Workarounds

There is no workaround as there is no known exploit scenario.

Original Report

RFC 9110 Secion 8.6 defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts "+" prefixed Content-Length, which could lead to potential HTTP request smuggling.

Payload:

POST / HTTP/1.1 Host: a.com Content-Length: +16 Connection: close ​ 0123456789abcdef

When sending this payload to Jetty, it can successfully parse and identify the length.

When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request.

This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS.

Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2.

Incomplete Cleanup vulnerability in Apache Tomcat.

When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.

Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue.

Improper Input Validation vulnerability in Apache Tomcat.

Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.81 and from 8.5.0 through 8.5.93 did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.

Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fix the issue.

Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. See the documentation for more details on correct cluster administration.

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAYLANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAYLANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAYLANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAYLANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

A specially crafted web page can abuse this vulnerability to cause memory corruption and potentially arbitrary code execution. A user would need to visit a malicious webpage to trigger this vulnerability.

Reference: https://webkitgtk.org/security/WSA-2023-0009.html#CVE-2023-39928

Null pointer dereference when composing from a specially crafted draft message in Mutt >1.5.2 <2.2.12

Null pointer dereference when viewing a specially crafted email in Mutt 1.5.2 <2.2.12

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.

A flaw was found in the OpenSSH package. For each ping packet the SSH server receives, a pong packet is allocated in a memory buffer and stored in a queue of packages. It is only freed when the server/client key exchange has finished. A malicious client may keep sending such packages, leading to an uncontrolled increase in memory consumption on the server side. Consequently, the server may become unavailable, resulting in a denial of service attack.