Chromium: CVE-2023-6112 Use after free in Navigation

A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.

Chromium: CVE-2023-5997 Use after free in Garbage Collection

A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing.

With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection.

This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2.

The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.

A out-of-bounds write flaw was found in the xorg-x11-server. This issue occurs due to an incorrect calculation of a buffer offset when copying data stored in the heap in the XIChangeDeviceProperty function in Xi/xiproperty.c and in RRChangeOutputProperty function in randr/rrproperty.c, allowing for possible escalation of privileges or denial of service.

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.

libcue provides an API for parsing and extracting data from CUE sheets. Versions 2.2.1 and prior are vulnerable to out-of-bounds array access. A user of the GNOME desktop environment can be exploited by downloading a cue sheet from a malicious webpage. Because the file is saved to ~/Downloads, it is then automatically scanned by tracker-miners. And because it has a .cue filename extension, tracker-miners use libcue to parse the file. The file exploits the vulnerability in libcue to gain code execution. This issue is patched in version 2.3.0.

Mbed TLS 2.x before 2.28.5 and 3.x before 3.5.0 has a Buffer Overflow.

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

In case of an error in smb3fscontextparseparam, ctx->password was freed but the field was not set to NULL which could lead to double free.

We recommend upgrading past commit e6e43b8aa7cd3c3af686caf0c2e11819a886d705.

Cookie HTTP header isn't stripped on cross-origin redirects

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

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

Chromium: CVE-2023-5217 Heap buffer overflow in vp8 encoding in libvpx

The Tungstenite crate before 0.20.1 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes).

A stack exhaustion flaw in control channel code may cause named to terminate unexpectedly

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.

Chromium: CVE-2023-4863 Heap buffer overflow in WebP

Last updated 24 July 2024

Last updated 24 July 2024

Chromium: CVE-2023-4762 Type Confusion in V8

.NET and Visual Studio Denial of Service Vulnerability

REJECT DO NOT USE THIS CVE RECORD. ConsultIDs: CVE-2023-4206, CVE-2023-4207, CVE-2023-4208. Reason: This record is a duplicate of CVE-2023-4206, CVE-2023-4207, CVE-2023-4208. Notes: All CVE users should reference CVE-2023-4206, CVE-2023-4207, CVE-2023-4208 instead of this record. All references and descriptions in this record have been removed to prevent accidental usage.

An infinite loop vulnerability was found in Samba's mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets sent by the client, the core unmarshalling function slunpackloop() did not validate a field in the network packet that contains the count of elements in an array-like structure. By passing 0 as the count value, the attacked function will run in an endless loop consuming 100% CPU. This flaw allows an attacker to issue a malformed RPC request, triggering an infinite loop, resulting in a denial of service condition.

Redis is an in-memory database that persists on disk. In Redit 7.0 prior to 7.0.12, extracting key names from a command and a list of arguments may, in some cases, trigger a heap overflow and result in reading random heap memory, heap corruption and potentially remote code execution. Several scenarios that may lead to authenticated users executing a specially crafted COMMAND GETKEYS or COMMAND GETKEYSANDFLAGSand authenticated users who were set with ACL rules that match key names, executing a specially crafted command that refers to a variadic list of key names. The vulnerability is patched in Redis 7.0.12.

iperf3 before 3.14 allows peers to cause an integer overflow and heap corruption via a crafted length field.

Microsoft Security Advisory CVE-2023-33170: .NET Security Feature Bypass Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 2.1 and above. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A vulnerability exist in ASP.NET Core applications where account lockout maximum failed attempts may not be immediately updated, allowing an attacker to try more passwords.

Discussion

Discussion for this issue can be found at https://github.com/dotnet/aspnetcore/issues/49334

Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

Affected software

Any ASP.NET 7.0 application running on .NET 7.0.8 or earlier. Any ASP.NET 6.0 application running on .NET 6.0.19 or earlier. Any ASP.NET Core 2.1 application consuming the package Microsoft.AspNetCore.Identity version 2.1.31 or earlier.

If your application uses the following package versions, ensure you update to the latest version of .NET.

ASP.NET Core 2.1

Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- Microsoft.AspNetCore.Identity | <=2.1.39 | 2.1.39

Microsoft.AspNet.Identity.Owin Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- Microsoft.AspNet.Identity.Owin | <= 2.2.3 | 2.2.4

ASP.NET 6.0

Package name | Affected version | Patched version ------------ | ---------------- | -------------------------

Microsoft.AspNetCore.App.Runtime.linux-arm | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.linux-arm64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.linux-x64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.osx-arm64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.osx-x64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.win-arm | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.win-arm64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.win-x64 | <= 6.0.19 | 6.0.20 Microsoft.AspNetCore.App.Runtime.win-x86 | <= 6.0.19 | 6.0.20

ASP.NET 7.0

Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- Microsoft.AspNetCore.App.Runtime.linux-arm | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.linux-arm64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.linux-x64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.osx-arm64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.osx-x64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.win-arm | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.win-arm64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.win-x64 | <= 7.0.9 | 7.0.9 Microsoft.AspNetCore.App.Runtime.win-x86 | <= 7.0.9 | 7.0.9

Advisory FAQ

How do I know if I am affected?

If you have a runtime or SDK with a version listed, or an affected package listed in affected software, you're exposed to the vulnerability.

How do I fix the issue?

To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs. If you are using one of the affected packages, please update to the patched version listed above. If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the dotnet --info command. You will see output like the following;

.NET Core SDK (reflecting any global.json):

Version: 6.0.300 Commit: 8473146e7d

Runtime Environment:

OS Name: Windows OS Version: 10.0.18363 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):

Version: 6.0.5 Commit: 8473146e7d

.NET Core SDKs installed:

6.0.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:

Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download

If you're using .NET 7.0, you should download and install Runtime 7.0.7 or SDK 7.0.106 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0. If you're using .NET 6.0, you should download and install Runtime 6.0.18 or SDK 6.0.312 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0. If you're using ASP.NET Core 2.1 and consuming the Microsoft.AspNetCore.Identity package, update that package to version 2.1.39

.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at <https://aka.ms/corebounty>.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2023-33170

Revisions

V1.0 (July 11, 2023): Advisory published.

Version 1.0

Last Updated 2023-07-11

CVE-2022-24834 - A specially crafted Lua script executing in Redis can trigger a heap overflow in the cjson and cmsgpack libraries, and result in heap corruption and potentially remote code execution. The problem exists in all versions of Redis with Lua scripting support, starting from 2.6, and affects only authenticated and authorized users.

https://github.com/redis/redis/security/advisories/GHSA-p8x2-9v9q-c838

Impact During file downloads, yt-dlp or the external downloaders that yt-dlp employs may leak cookies on HTTP redirects to a different host, or leak them when the host for download fragments differs from their parent manifest's host.

This vulnerable behavior is present in all versions of youtube-dl, youtube-dlc and yt-dlp released since 2015.01.25. All native and external downloaders are affected, except for curl and httpie (httpie version 3.1.0 or later).

At the file download stage, all cookies are passed by yt-dlp to the file downloader as a Cookie header, thereby losing their scope. This also occurs in yt-dlp's info JSON output, which may be used by external tools. As a result, the downloader or external tool may indiscriminately send cookies with requests to domains or paths for which the cookies are not scoped.

An example of a potential attack scenario exploiting this vulnerability: 1. an attacker has crafted a malicious website with an embedded URL designed to be detected by yt-dlp as a video download. This embedded URL has the domain of a trusted site that the user has loaded cookies for, and conducts an unvalidated redirect to a target URL. 2. yt-dlp extracts this URL and calculates a Cookie header based on its domain for the file downloader to make its request(s) with. 3. the download URL redirects to a server controlled by the attacker, to which yt-dlp forwards the user's sensitive cookie information.

Patches yt-dlp version 2023.07.06 fixes this issue by doing the following:

- Remove the Cookie header upon HTTP redirects - Have native downloaders calculate their own Cookie header from the cookiejar - Utilize external downloaders' built-in support for cookies instead of passing them as header arguments - If the external downloader does not have proper cookie support, then disable HTTP redirection (axel only) - Process cookies passed as HTTP headers to limit their scope (--add-header "Cookie:..." is scoped to input URL domain only) - Store cookies in a separate cookies field of the info dict instead of httpheaders so as not to lose their scope

Patches for youtube-dl are expected and we will update this advisory when they are merged.

Workarounds It is recommended to upgrade yt-dlp to version 2023.07.06 as soon as possible.

For users who are not able to upgrade:

- Avoid using cookies and user authentication methods (--cookies, --cookies-from-browser, --username, --password, --netrc). While extractors may set custom cookies, these usually do not contain sensitive information. - Avoid using --load-info-json

Or, if authentication is a must:

- Verify the integrity of download links from unknown sources in browser (including redirects) before passing them to yt-dlp - Use curl as external downloader, since it is not impacted (--downloader curl) - Avoid fragmented formats such as HLS/m3u8, DASH/mpd and ISM (use -f "(bv+ba/b)[protocol~='^https?$']")

References - https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj - https://nvd.nist.gov/vuln/detail/CVE-2023-35934 - https://github.com/yt-dlp/yt-dlp/releases/tag/2023.07.06 - https://github.com/yt-dlp/yt-dlp-nightly-builds/releases/tag/2023.07.06.185519 - https://github.com/yt-dlp/yt-dlp/commit/1ceb657bdd254ad961489e5060f2ccc7d556b729 - https://github.com/yt-dlp/yt-dlp/commit/f8b4bcc0a791274223723488bfbfc23ea3276641 - https://github.com/yt-dlp/yt-dlp/commit/3121512228487c9c690d3d39bfd2579addf96e07

Last updated 18 March 2026