1121984919

Weaknesses in TLS certificate identity validation occur within the `tls verify certificate()`, `tls match hostname()`, and `x509 utils get dns names()` functions. The software uses custom Common Name and DNS SAN string matching instead of OpenSSL's length-aware identity validation APIs. This leads to three issues: DNS SAN values are truncated at embedded NUL bytes, a matching Common Name is accepted even if non-matching DNS SAN entries exist, and IP-literal targets are accepted via DNS/CN matching without comparing iPAddress SANs. An attacker with a trusted or misissued certificate chain can bypass server identity verification, compromising TLS server authentication.

A null pointer dereference occurs in smartcard cache request decoders when they accept NULL NDR pointers for `LookupName` during `SCARD IOCTL READCACHEA` and `SCARD IOCTL WRITECACHEA` operations. If smartcard emulation is enabled, an attacker can send crafted smartcard cache requests with NULL lookup-name pointers to trigger the `strlen()` function on a null pointer, leading to the termination of the client process.

A client-side heap use-after-free issue exists in the async update message proxy for RAIL WINDOW STATE ORDER and NOTIFY ICON STATE ORDER when AsyncUpdate is enabled. A malicious or compromised RDP server can send crafted update orders causing the message proxy to shallow-copy structures containing nested parser-owned pointers, such as `titleInfo.string`, `windowRects`, `visibilityRects`, and icon buffers. Because the parser frees these nested buffers after the callback returns, the queued async message dispatches stale pointers, which can lead to memory corruption or a client crash.

Improper validation of the Extended Key Usage (EKU) purpose occurs during client-side server TLS authentication. Within the `x509 utils verify()` function, if the server-purpose (X509 PURPOSE SSL SERVER) verification fails, the system incorrectly falls back to client-purpose and any-purpose verification. This allows a trusted certificate that matches the hostname but is only valid for client authentication to be accepted as a legitimate RDP server certificate, bypassing purpose validation in environments that separate client and server certificate roles.

[Content removed]

Insufficient validation of server-supplied RDPDR paths during drive redirection allows a malicious RDP server to access prefix-sibling paths outside the configured shared root. By sending non-rooted paths that bypass the shared-root boundary check, an attacker can read, write, delete, and enumerate files in sibling directories.

A denial of service issue exists in the RDPEI server channel handler. The component fails to validate the maximum PDU (Protocol Data Unit) body length before allocating the stream. A malicious RDP client can trigger excessive memory allocation on the server by sending a header-only RDPEI message with a large declared body length.

An improper certificate hostname validation issue exists where the TLS hostname matcher `tls match hostname()` in libfreerdp/crypto/tls.c incorrectly handles wildcard patterns. Specifically, a pattern like *.example.com is treated as matching any hostname ending in .example.com, allowing wildcard certificates to be accepted for multi-label subdomains such as a.b.example.com. This behavior weakens TLS server authentication.

Insufficient validation of CRLF and control characters occurs in the server-controlled RDP redirection `TargetNetAddress` field. This value is assigned to the client's `ServerHostname` and is subsequently written into the proxy CONNECT request line and Host header by the `http proxy connect()` function without filtering when connecting through an HTTP proxy. A compromised or malicious RDP server can send a crafted redirection PDU (Protocol Data Unit) containing embedded control characters to inject arbitrary headers or requests into the HTTP proxy CONNECT request.

A heap out-of-bounds read exists in the `update process glyph fragments()` and `glyph cache fragment put()` functions within libfreerdp/cache/glyph.c. The issue occurs during the handling of a GLYPH FRAGMENT ADD update, where the system reads a one-byte server-controlled declared fragment size without verifying if it fits within the remaining received buffer before allocation and copying. A malicious RDP server can trigger this by sending a short fragment with an oversized declared size, causing the client to read beyond the allocated buffer and crash.

A heap buffer overflow exists in the server-side RAIL channel handler. The issue occurs within the `rail server handle messages()` function in `channels/rail/server/rail main.c` when processing a RAIL PDU header. The software subtracts `RAIL PDU HEADER LENGTH` from the peer-controlled `orderLength` field without verifying that `orderLength` is at least the header length. If `orderLength` is between 0 and 3, an unsigned integer underflow occurs, resulting in a very large size that bypasses the `Stream EnsureRemainingCapacity()` capacity check via pointer arithmetic wraparound. This value is then passed to `WTSVirtualChannelRead()`, leading to an out-of-bounds heap write. A malicious or compromised RDP client can exploit this to corrupt the heap and crash the server.

A heap out-of-bounds read occurs in the TSMF FFmpeg decoder when parsing AVC1 MPEG2VIDEOINFO media types that have insufficient `ExtraData`. A remote attacker can trigger a crash by sending malformed media format data from a server, which causes the system to read fixed offsets without validating the source buffer length.

The `WindowsViewer.get command()` function constructs a cmd.exe shell command by embedding a file path into an f-string without proper escaping. This result is then passed to `subprocess.Popen(..., shell=True)`, which allows the injection of arbitrary cmd.exe commands via shell metacharacters within the file path.