OpenBSD LibreSSL ocspcheck memory exhaustion via unbounded OCSP HTTP responses

LibreSSL ocspcheck through 4.4.0 contains a memory exhaustion vulnerability that allows malicious OCSP responders to exhaust memory by sending unbounded HTTP responses. Attackers controlling the responder or intercepting plain HTTP AIA OCSP traffic can stream endless headers or body data to http_head_read() and http_body_read(), denying certificate status checks.

• OpenBSD LibreSSL: the confirmed affected range is from 0 through and including 4.4.0, using semver. The affected component is ocspcheck and its HTTP response-reading logic.
• The record sets the default status to unaffected outside the stated affected range.
• The record does not establish the status of parallel branches or releases beyond this range; later releases must not be assumed safe without verification.

The flaw is in ocspcheck HTTP response handling, specifically the http_head_read() and http_body_read() functions. While reading headers, the affected implementation repeatedly grows its buffer until it finds the header terminator, without a header-size limit. While reading the body, it continues to grow the body buffer as data arrives, allowing a responder to stream indefinitely and force progressively larger allocations. Exploitation requires ocspcheck to make a network connection to an OCSP responder, with the attacker either controlling that responder or intercepting plain HTTP AIA OCSP traffic. This is CWE-770, with the confirmed result being memory exhaustion and denial of certificate status checks. The available evidence does not establish the exact behavior of every deployment after allocation failure.

• Reachability: The issue is remotely reachable over the network when the system performs an OCSP query.
• Conditions: The attacker must control the OCSP responder or intercept OCSP AIA traffic that uses plain HTTP. The record indicates that authentication and user interaction are not required.
• Exploitation status: The record marks public_exploit as false and does not mark the vulnerability as known exploited; the reviewed materials do not describe a specific campaign or exploit.
• Limit: The absence of a recorded public exploit does not prove that exploitation has never occurred.

• The confirmed technical outcome is that ocspcheck can consume unbounded memory when it receives an HTTP header or body that does not terminate.
• This can exhaust process or system memory and cause certificate status checks to be denied or fail.
• The record does not indicate an effect on confidentiality or integrity; the primary impact is availability of certificate status checks.
• If the process shares resources with other workloads, memory pressure could affect those workloads, but that is a possible consequence rather than an independently confirmed impact.

• Workflows that depend on certificate status checks may hang, fail, or return errors when ocspcheck is forced to allocate memory continuously.
• Rising memory consumption may place pressure on the host or co-located workloads, although the available evidence does not confirm a broader impact beyond availability degradation.
• The issue is described as an availability problem; the record provides no evidence that an attacker can read or modify protected data.
• Systems performing network-based OCSP checks should be prioritized, particularly where the connection uses plain HTTP and can be intercepted.

1. Update LibreSSL to a vendor release or build that contains both upstream changes limiting HTTP response sizes. A patch is available, but the record does not provide an exact fixed release, so a specific release must not be assumed safe without verification.
2. If a source build or backport is required, verify that the code limits HTTP headers to 64 KB and rejects OCSP bodies larger than 20 KB. These limits correspond to the upstream ocspcheck changes.
3. Prioritize systems that perform certificate status checks against responders reachable from the network.
4. While patching, avoid plain HTTP AIA OCSP retrieval where the deployment architecture permits. This is only a partial risk reduction and does not address a malicious responder.
5. After updating, retest OCSP checking workflows and monitor memory use during responder queries.

1. Inventory LibreSSL installations and identify systems that deploy or invoke ocspcheck; compare installed versions with the affected boundary in affected_summary.
2. Identify certificate-validation workflows that obtain OCSP locations from AIA, especially workflows using plain HTTP.
3. Review network telemetry from systems running ocspcheck for connections to OCSP responders with unusually long durations or continuously growing responses. This is precautionary monitoring, not a confirmed IOC.
4. Monitor memory use by the process or workload performing OCSP checks during responder queries. Abnormal growth can support detection but is not sufficient by itself.
5. The available material does not provide a specific log signature or IOC; absence of abnormal log evidence should not be treated as proof that a system is safe.