See how red hat compares to other vendors in security performance
A flaw was found in sssd, specifically within the PAM (Pluggable Authentication Modules) responder's protocol v1 parser, pamparseindata(). A local client with access to the PAM responder's UNIX socket can exploit this by negotiating protocol v1 and sending an empty or truncated PAM request body. This can trigger an out-of-bounds read, potentially causing the PAM responder to terminate or restart, leading to a local denial of service.
A flaw was found in the sssd NSS responder. This input validation vulnerability allows a local attacker, by sending specially crafted service lookup requests to the NSS responder's UNIX socket, to cause an out-of-bounds read. This out-of-bounds read may lead to a denial of service (DoS) by crashing the NSS responder process. While unprivileged local clients can typically reach the socket, there is no evidence of privilege escalation or reliable data disclosure.
A denial-of-service vulnerability was discovered in skupper-router within the AMQP field parser. The flaw is caused by unbounded recursion when processing deeply nested or specially crafted AMQP messages, leading to a stack overflow. An attacker who can send messages to the router can trigger this crash. Exploitation requires the attacker to possess a valid x.509 certificate signed by the Red Hat Service Interconnect network's certificate authority. Successful exploitation results in the skupper-router process crashing, terminating all active connections and preventing new traffic from being routed through the affected node.
AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS Risk in NSS Responder Due to Zero-Length Request Body Underflow: crafted header-only NSS requests can force blen == 0 in parsers that inspect body[blen - 1], and if the final header byte is '\0' the path can continue into sssutf8check(body, SIZEMAX), creating a local denial-of-service condition in the NSS responder. Requirements to exploit: Ability to run code as a local unprivileged user on a system where the NSS responder is enabled and reachable through its UNIX socket, and to send a crafted 16-byte request to an affected parser such as SSSNSSGETPWNAM. Component affected: sssd-2.12.0-1.el10; NSS responder request parsing in src/responder/nss/nssprotocol.c (sssnssprotocolparsename, sssnssprotocolparsesvcname, sssnssprotocolparsesvcport, sssnssprotocolparsecert, and sssnssprotocolparsesid) Version affected: sssd-2.12.0-1.el10 when the NSS responder is enabled and reachable through its local UNIX socket Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not yet established. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.9 (LOW) AV:L - Exploitation requires local access to the host and the NSS responder UNIX socket. AC:L - A single crafted 16-byte header-only request is sufficient to reach the vulnerable parsing path. PR:N - No prior privileges are required if the local user can connect to the responder socket. UI:N - No user interaction is needed. S:U - The impact is limited to the NSS responder within the same security scope. C:N - No confidentiality impact was demonstrated. I:N - No integrity impact was demonstrated. A:L - The demonstrated outcome is local responder instability or termination; broader or reliably repeatable impact was not established from the available evidence. Impact: Moderate. A local unprivileged user can affect availability of a system responder with a simple malformed request, which fits Red Hat's Moderate category for flaws that can still cause some availability compromise under constrained conditions. It does not fit Important or Critical because no remote attack path, privilege gain, confidentiality impact, or integrity impact was established. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited to denial of service in the NSS responder, and the fix is a small validation change. Acknowledgement: Aisle Research Vulnerability Details: In src/responder/nss/nssprotocol.c, multiple NSS request parsers obtain the request body and immediately test body[blen - 1] without first ensuring that blen is non-zero. The SSSNSSGETPWNAM path reaches sssnssprotocolparsename(), and similar logic appears in sssnssprotocolparsesvcname(), sssnssprotocolparsesvcport(), sssnssprotocolparsecert(), and sssnssprotocolparsesid(). c ... ssspacketgetbody(pctx->creq->in, &body, &blen); / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated!\n"); return EINVAL; } / If the body isn't valid UTF-8, fail / if (!sssutf8check(body, blen - 1)) { DEBUG(SSSDBGCRITFAILURE, "Body is not UTF-8 string!\n"); return EINVAL; } ... ssspacketgetbody() derives the body length directly from the packet length: c void ssspacketgetbody(struct ssspacket packet, uint8t body, sizet blen) { body = packet->buffer + SSSPACKETBODYOFFSET; blen = ssspacketgetlen(packet) - SSSNSSHEADERSIZE; } A header-only request with len == SSSNSSHEADERSIZE therefore yields blen == 0. In that case, the first body[blen - 1] access reads the last byte of the packet header rather than necessarily moving outside the packet allocation. However, if that header byte is '\0', sssnssprotocolparsename() continues into sssutf8check(body, blen - 1) with blen - 1 == SIZEMAX, creating an effectively unbounded UTF-8 validation read. Based on the available evidence, that is sufficient for a realistic local denial of service against the NSS responder, while broader memory corruption or confidentiality/integrity impact was not established. Steps to reproduce: 1. Ensure SSSD is running with the NSS responder enabled and identify the NSS socket, commonly /var/lib/sss/pipes/nss. 2. Connect to that UNIX socket as an unprivileged local user. 3. Send a 16-byte header-only request using a command that reaches sssnssprotocolparsename(), such as SSSNSSGETPWNAM (0x0011), with len = 16, status = 0, and reserved = 0. 4. Observe the responder under ASan, Valgrind, or equivalent crash monitoring. The parse path reaches body[blen - 1] with blen == 0 and may continue into large-length UTF-8 validation. 5. Repeating the crafted request can destabilize or terminate the NSS responder process. python import socket, struct sock = "/var/lib/sss/pipes/nss" # adjust if needed hdr = struct.pack("<IIII", 16, 0x0011, 0, 0) # len, cmd, status, reserved s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.connect(sock) s.sendall(hdr) try: print(s.recv(4096)) except Exception as e: print("recv error:", e) s.close() Mitigation: The demonstrated attack path requires local access to the NSS responder UNIX socket. Environments that do not expose that socket to untrusted local users are not exposed to the demonstrated path. Where operationally acceptable, disabling the NSS responder until a fixed package is available removes the vulnerable surface. Proposed Fix: Add an explicit blen == 0 check before any body[blen - 1] access in the affected NSS parsers. diff diff --git a/src/responder/nss/nssprotocol.c b/src/responder/nss/nssprotocol.c index 0000000..0000000 100644 — a/src/responder/nss/nssprotocol.c +++ b/src/responder/nss/nssprotocol.c @@ -112,6 +112,11 @@ sssnssprotocolparsename(struct clictx clictx, const char rawname) ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBGCRITFAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated!\n"); return EINVAL; @@ -270,6 +275,11 @@ sssnssprotocolparsesvcname(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBGCRITFAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; @@ -326,6 +336,11 @@ sssnssprotocolparsesvcport(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBGCRITFAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; @@ -372,6 +387,11 @@ sssnssprotocolparsecert(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBGCRITFAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; @@ -416,6 +436,11 @@ sssnssprotocolparsesid(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + DEBUG(SSSDBGCRITFAILURE, "Body is empty!\n"); + return EINVAL; + } + if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; ------ This report was generated using AI technology. Always review AI-generated content prior to use
AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in PAM responder: NULL dereference in getdomainrequesttype() when SSSPAMITEMSERVICE is omitted: a crafted local PAM protocol v2/v3 request that omits the service item can leave pd->service as NULL and trigger a NULL dereference in the PAM responder when [pam] pamappservices is configured, causing denial of service. Requirements to exploit: Local access sufficient to connect to the PAM responder socket and send a crafted PAM protocol v2/v3 request that omits SSSPAMITEMSERVICE; the target must use a non-empty [pam] pamappservices configuration. Component affected: sssd-2.12.0-1.el10, PAM responder code in src/responder/pam/pamsrvcmd.c, specifically pamparseindatav2(), pamparseindatav3(), pamforwarder(), and getdomainrequesttype(). Version affected: sssd-2.12.0-1.el10; reachability depends on a non-empty [pam] pamappservices configuration. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - The issue is reachable only from the local system through the PAM responder's UNIX socket. AC:L - A valid request can be crafted without unusual conditions once the protocol framing and required fields are understood. PR:L - The attacker needs local access equivalent to an unprivileged user that can submit requests to the PAM responder interface. UI:N - No user interaction is required. S:U - The crash affects the same security scope as the vulnerable responder. C:N - No confidentiality impact was established. I:N - No integrity impact was established. A:H - A successful trigger can terminate the PAM responder and block authentication requests handled through it until the service recovers. Impact: Moderate. This is an availability-only issue in a security-relevant local service, but exploitation is local and depends on a non-default yet supported pamappservices deployment. That places it below Important under Red Hat guidance, while remaining above Low because the NULL dereference condition is concrete and can be triggered with a crafted request rather than being purely theoretical. Embargo: no Reason: Current evidence supports a local, configuration-dependent denial of service with straightforward mitigation and no demonstrated confidentiality, integrity, or privilege-escalation impact. Acknowledgement: Aisle Research Vulnerability Details: In PAM protocol v2/v3 request parsing, SSSPAMITEMSERVICE is optional, so the service pointer may remain unset: c case SSSPAMITEMSERVICE: ret = extractstring(&pd->service, size, body, blen, &c); if (ret != EOK) return ret; break; The parsed request is then forwarded unconditionally into domain selection: c preq->reqdomtype = getdomainrequesttype(preq, pctx); getdomainrequesttype() compares configured application services against preq->pd->service without checking for NULL: c for (int i = 0; pctx->appservices[i]; i++) { if (strcmp(pctx->appservices[i], preq->pd->service) == 0) { reqdomtype = CACHEREQAPPLICATIONDOM; break; } } When [pam] pamappservices is non-empty and the request omits SSSPAMITEMSERVICE, the responder can reach strcmp(nonnull, NULL) and terminate with a NULL pointer dereference. The established impact from the available evidence is denial of service in the PAM responder. Relevant CWE: CWE-476 (NULL Pointer Dereference). Steps to reproduce: 1. Configure SSSD with a non-empty [pam] pamappservices value, for example pamappservices = appsvc, and restart the service. 2. Connect locally to the PAM responder socket. In standard builds this is the SSSPAMSOCKETNAME path, commonly /var/lib/sss/pipes/pam. 3. Send a valid PAM protocol v3 request with correct SSSSTARTOFPAMREQUEST / SSSENDOFPAMREQUEST framing, a supported command such as SSSPAMAUTHENTICATE, and the fields needed for parser success, including SSSPAMITEMCLIPID and a user or logon value. 4. Omit SSSPAMITEMSERVICE from the request. 5. Observe the request reach getdomainrequesttype() and dereference preq->pd->service == NULL via strcmp(), causing the PAM responder process to crash. Mitigation: Until a fix is applied, avoid configuring pamappservices where it is not operationally required. If that setting must remain enabled, limit local ability to submit raw PAM responder requests as far as deployment policy allows and monitor for PAM responder crashes. Proposed Fix: Add a NULL check before comparing preq->pd->service against entries in pctx->appservices[]. This preserves the existing application-domain selection behavior for valid service names while avoiding the NULL dereference on requests that omit SSSPAMITEMSERVICE. diff diff --git a/src/responder/pam/pamsrvcmd.c b/src/responder/pam/pamsrvcmd.c index <old>..<new> 100644 — a/src/responder/pam/pamsrvcmd.c +++ b/src/responder/pam/pamsrvcmd.c @@ -1857,8 +1857,10 @@ getdomainrequesttype(struct pamauthreq preq, / By default, only POSIX domains are to be contacted / reqdomtype = CACHEREQPOSIXDOM; for (int i = 0; pctx->appservices[i]; i++) {
if (strcmp(pctx->appservices[i], preq->pd->service) == 0) { + for (int i = 0; pctx->appservices[i]; i++) { + if (preq->pd->service != NULL + && strcmp(pctx->appservices[i], + preq->pd->service) == 0) { reqdomtype = CACHEREQAPPLICATIONDOM; break; }
------ This report was generated using AI technology. Always review AI-generated content prior to use
Moderate: perl:5.32 security update
Moderate: libkcapi security, bug fix, and enhancement update
Moderate: Red Hat Certificate System 10.4.4 security and bug fix update for RHEL 8
A vulnerability was found in Keycloak-services package. If untrusted data is passed to the method (SearchQueryUtils), it could lead to a denial-of-service scenario by exhausting system resources.
A flaw was found in multipathd. A local attacker with access to the multipathd UNIX control socket can exploit this vulnerability by sending valid commands and then ceasing to read replies. This action can cause the multipathd listener thread to block, leading to a Denial of Service (DoS) where legitimate Inter-Process Communication (IPC) operations may hang or time out. This issue does not result in privilege escalation, arbitrary code execution, or impact data confidentiality or integrity.
A container privilege escalation flaw was found in certain Ansible Automation Platform images. This issue arises from the /etc/passwd file being created with group-writable permissions during the build process. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This vulnerability allows an attacker to add a new user with any arbitrary UID, including UID 0, gaining full root privileges within the container.
A flaw was found in OpenSSH. A malicious SSH server can exploit a double free vulnerability in the Diffie-Hellman Group Exchange (DH-GEX) client path. This occurs during FIPS (Federal Information Processing Standards) mode known-group validation when the client processes attacker-controlled DH-GEX group parameters. Successful exploitation leads to client-side process termination, resulting in a Denial of Service (DoS).
Moderate: gstreamer1-plugins-base security update
A flaw was found in Red Hat Quay's Proxy Cache configuration feature. When an organization administrator configures an upstream registry for proxy caching, Quay makes a network connection to the specified registry hostname without verifying that it points to a legitimate external service. An attacker with organization administrator privileges could supply a crafted hostname to force the Quay server to make requests to internal network services, cloud infrastructure endpoints, or other resources that should not be accessible from the Quay application.
PCS (Pacemaker Configuration System) has an arbitrary file read vulnerability in the pcs host auth --token <path> command path. When a non-root user in the 'haclient' group runs this command, the nonrootrun() function in pcs/app.py forwards it to the locally running pcsd daemon via HTTP POST to /runpcs. The pcsd daemon (running as root) matches the command against its allowedcommands list in pcsd/pcsd.rb (['host', 'auth', '...']) with no restriction on --token, and re-executes PCS as root. This causes utils.gettokenfromfile() in pcs/utils.py to open and read the attacker-specified file path with root privileges, reading up to 256 bytes. The file contents are base64-encoded and stored as a token in the known-hosts configuration file. The attacker can exfiltrate the file contents by triggering node communication (e.g., pcs pcsd status) and intercepting the HTTP Cookie header containing the base64-encoded token.
Affected: PCS versions from 0.10.8 onwards (introduced in commit 9178b78d11baa70e700a5c0d9fc1c17f27d452fa). RHEL 8.4+, RHEL 9.0+, and RHEL 10.0+ ship affected PCS versions.
Fix: Upstream patch attached to PSIRTSUPT-22935 (commit b41eaf3c6e2ecfc575c42442fb02b8ef05b4dd6a, not yet on public GitHub main). Blocks pcs host auth --token for non-root users in both pcs/app.py and pcsd/pcsd.rb.
Reporter: Peter Romancik (PCS upstream developer, Red Hat). PSIRT ticket: PSIRTSUPT-22935
A denial-of-service vulnerability was discovered in skupper-router within the AMQP field parser. The flaw is caused by unbounded recursion when processing deeply nested or specially crafted AMQP messages, leading to a stack overflow. An attacker who can send messages to the router can trigger this crash. Exploitation requires the attacker to possess a valid x.509 certificate signed by the Red Hat Service Interconnect network's certificate authority. Successful exploitation results in the skupper-router process crashing, terminating all active connections and preventing new traffic from being routed through the affected node.
A flaw was found in Red Hat Quay's repository-level mirror configuration feature. The POST and PUT handlers in endpoints/api/mirror.py accept an externalreference parameter without SSRF validation, unlike the organization-level mirror handlers which apply validateexternalregistryurl(). A repository administrator can supply a crafted hostname that causes the Quay mirror worker to make requests via Skopeo to internal network services, cloud metadata endpoints, or other resources not intended to be reachable from the Quay application.
A flaw was found in the key provider component of the keycloak-services library, which is the core engine for the Red Hat Build of Keycloak. The issue occurs because a previous fix for path probing was incomplete, allowing a realm administrator to still submit arbitrary filesystem paths as keystore parameters. This can be used to determine the existence and readability of files on the server, potentially exposing sensitive system information.
Moderate: gstreamer1-plugins-good security update
Moderate: gstreamer1-plugins-good security update
Moderate: glib2 security update