CVE-2023-38200
Executive Summary
CVE-2023-38200 is a remotely exploitable denial-of-service (DoS) vulnerability affecting the Keylime registrar component. The registrar's SSL connection handling is blocking in nature, which allows an unauthenticated remote attacker to exhaust all available connection slots, effectively rendering the registrar unavailable to legitimate clients. With a CVSS base score of 7.5 (High), this vulnerability carries significant availability impact but does not compromise confidentiality or integrity. The patch status remains uncertain (2/4 confidence, single-source claim only), and no public exploit code, PoC, or CISA KEV listing has been identified at the time of this report. Keylime deployments — particularly those exposing the registrar to untrusted networks — are at immediate risk.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability resides in the Keylime registrar component, an HTTPS-facing service responsible for managing device identity and attestation data. According to the NVD description, the flaw stems from the "blocking nature" of the registrar's SSL connection handling.
The attack mechanism is a classic resource exhaustion flaw in the connection-accept loop:
- Blocking I/O with insufficient connection limit enforcement: The registrar's SSL/TLS handshake and connection-accept logic operates in a blocking fashion. When an attacker opens multiple simultaneous TCP connections to the registrar's SSL port without completing handshakes (e.g., sending incomplete TLS ClientHello messages or simply holding sockets open), each connection consumes a thread, file descriptor, or connection slot.
- No connection rate throttling: The description indicates there is no embedded mechanism to reject or time out excess connections, allowing an attacker to progressively fill all available connection slots.
- Full resource exhaustion: Once all connection slots are occupied by attacker-controlled half-open or stalled connections, legitimate clients — including agents attempting to register, verify attestation, or manage keys — are unable to establish new SSL sessions. The registrar becomes fully unresponsive to legitimate traffic.
The vulnerability class aligns with CWE-400: Uncontrolled Resource Consumption, though the NVD entry does not explicitly assign a CWE. The root cause is architectural: the registrar was not designed to handle connection-queue saturation under adversarial conditions, nor does it appear to implement connection-level rate limiting or per-IP quotas.
The attack surface is the registrar's SSL listening port, which is typically exposed on TCP port 443 or a custom port. The description notes the attack leverages "remote" access, meaning no prior authentication or network position beyond network reachability to the registrar's SSL port is required.
Specific technical detail is limited: The NVD description does not disclose function names, file paths, or code-level specifics. The blocking I/O flaw is the only mechanism named. Attackers require only network access to the SSL service; no credentials or preconditions are mentioned in the available data.
Exploitation Scenarios
Scenario: Distributed SSL Connection Saturation Against Publicly Exposed Registrar
Step 1 — Reconnaissance (Target Identification): An attacker identifies a Keylime registrar by scanning for open SSL/TLS ports (typically 443 or alternate ports) and fingerprinting the service via TLS certificate metadata (e.g., certificate subject containing "registrar" or Keylime-specific identifiers) or by observing protocol characteristics in the TLS handshake. Tools like Shodan or masscan can identify exposed services. The attacker may also leverage known Keylime deployment patterns to locate registrar endpoints, as registrars are commonly exposed to allow remote device enrollment.
Step 2 — Flaw Trigger (Connection Exhaustion): The attacker initiates a high volume of TLS connections to the registrar's SSL port. Crucially, the attacker does not need to complete the TLS handshake — the blocking nature of the registrar's connection handling means each half-open connection (e.g., TLS ClientHello sent, then silence) persists and consumes a connection slot. The attacker can use a single source or a botnet to launch thousands of concurrent connections. Because the registrar's connection handling is blocking and lacks throttling, each connection occupies one of the finite connection slots allocated to the service.
Step 3 — Payload/Execution (Resource Saturation):
The attack is executed via raw TCP/TLS connection flooding. The "payload" is simply a sustained stream of connection attempts — either incomplete TLS handshakes or connections that send minimal data and then stall. The attacker maintains these connections open for as long as possible to maximize slot occupancy. Tools such as slowloris (adapted for TLS) or simple multi-threaded socket scripts can generate the required volume. The blocking I/O flaw means the server cannot reject these connections quickly nor time them out, so the connection pool fills to capacity.
Step 4 — Post-Exploitation Impact (Availability Loss): Once all connection slots are exhausted, the registrar can no longer accept new SSL connections. Legitimate Keylime agents attempting to register, renew attestation keys, or perform integrity measurements are denied service. In large-scale deployments, this can halt the entire attestation lifecycle: new devices cannot be enrolled, existing devices cannot refresh their attestation state, and security monitoring becomes blind. The DoS persists as long as the attacker maintains the connection flood; upon termination of the attack, the registrar may recover if no permanent resource damage (e.g., memory exhaustion leading to crash) occurs. However, if the blocking behavior also ties up threads that are not released, the process may require a restart.
Note: No public PoC or exploit code is available; the attack chain described above is inferred from the vulnerability class (blocking SSL connection DoS) per the NVD description. No public PoC available; attack chain is inferred from vulnerability class.
Impact Assessment
| Factor | Assessment |
|---|---|
| CVSS Score | 7.5 (High) — as assigned by the CNA |
| Attack Vector | Network (remote, no authentication required) |
| Attack Complexity | Low — the attack does not require special conditions or user interaction |
| Confidentiality Impact | None (C:N) |
| Integrity Impact | None (I:N) |
| Availability Impact | High (A:H) — complete loss of registrar availability |
| User Interaction | None required |
| Business Impact | The registrar is the central trust anchor for Keylime deployments. A sustained DoS prevents device enrollment, attestation verification, and key revocation. Security operations are effectively blinded — compromised or non-compliant devices cannot be detected or remediated during the outage. In regulated environments, this may constitute a compliance failure. |
| Blast Radius | All devices and agents relying on the registrar for attestation. In multi-tenant or edge deployments, the blast radius can encompass hundreds to thousands of managed devices. The registrar is a single point of failure by design, amplifying the impact of this DoS. |
| EPSS Assessment | EPSS score of 0.01436 (70.7th percentile) suggests low active exploitation probability, but the percentile indicates the vulnerability is more likely to be explored than the majority of known CVEs. The absence of KEV listing and public PoC reduces immediate weaponization risk. |
| CISA KEV | Not listed — no evidence of in-the-wild exploitation observed to date. |
Detection Guidance
Sigma Rule
title: Keylime Registrar SSL Connection Exhaustion Attempt
id: 55c0df42-92a5-4f9b-a84e-71d5e1f3a9b4
status: experimental
description: Detects a high volume of SSL/TLS connections to the Keylime registrar service without completion of handshakes, indicating a potential connection-exhaustion DoS attack.
logsource:
category: network_connection
product: linux
detection:
selection:
EventID: 5156 # Windows Filtering Platform connection event; adapt for Linux auditd/netflow
dst_port: 443 # Adjust to actual registrar SSL port
condition: selection
timeframe: 60s
threshold: 500 # Connection attempt rate; tune based on normal baseline
fields:
- src_ip
- dst_ip
- dst_port
- process_name
falsepositives:
- Legitimate high-rate device enrollment bursts
- Monitoring/scanning tools
level: high
tags:
- attack.t1498
- cve.2023-38200
YARA Rule
rule Detect_Keylime_SSL_DoS_Signature
{
meta:
author = "ValtersIT SOC"
description = "Detects network flow data or packet captures showing excessive incomplete TLS handshakes to Keylime registrar"
CVE = "CVE-2023-38200"
strings:
$tls_clienthello = { 16 03 01 } // TLS 1.0 ClientHello
$tls_clienthello_12 = { 16 03 03 } // TLS 1.2 ClientHello
$tls_clienthello_13 = { 16 03 01 } // TLS 1.3 ClientHello (legacy version)
condition:
// Detect a high frequency of ClientHello messages without ServerHello responses
#tls_clienthello > 1000 or #tls_clienthello_12 > 1000 or #tls_clienthello_13 > 1000
}
Note: This YARA rule is designed for use on NetFlow/packet-capture archives. It detects signature volumes of TLS ClientHello packets, which would be abnormally high during a connection-exhaustion attack.
Suricata IDS Rule
alert tcp any any -> any 443 (msg:"ET DOG Keylime Registrar SSL Connection Exhaustion (CVE-2023-38200)"; flow:to_server,no_state; dsize:<100; content:"|16 03|"; depth:2; threshold:type both, track by_src, count 200, seconds 60; classtype:attempted-dos; cve:2023-38200; sid:2024083101; rev:1;)
Explanation: This rule alerts on a source IP sending more than 200 TLS ClientHello packets (small packets, <100 bytes, beginning with the TLS handshake bytes 16 03) within 60 seconds. This excessive ClientHello rate without completed handshakes is indicative of SSL connection exhaustion.
Elastic Detection
// Detect burst of TLS connections to registrar without completed handshakes
sequence by source.ip
with maxspan=60s
[network where destination.port == 443 and network.protocol == "tls" and event.action == "connection_attempted"]
[network where destination.port == 443 and network.protocol == "tls" and event.action == "connection_attempted"]
[network where destination.port == 443 and network.protocol == "tls" and event.action == "connection_attempted"]
[network where destination.port == 443 and network.protocol == "tls" and event.action == "connection_attempted"]
[network where destination.port == 443 and network.protocol == "tls" and event.action == "connection_attempted"]
Note: This EQL rule detects 5 or more TLS connection attempts from a single source within 60 seconds. For production, adjust the threshold upward (e.g., 50–200 attempts) to reduce false positives, based on the normal enrollment burst rate.
Splunk SPL Query
index=network sourcetype=flow_connection
| where dst_port=443
| stats count as conn_count, values(dst_ip) as registrar_ip, values(src_port) as src_ports by src_ip, _time
| bucket _time span=60s
| where conn_count > 200
| table _time, src_ip, registrar_ip, conn_count, src_ports
| sort - conn_count
Explanation: This query aggregates network flow data by source IP over 60-second buckets, filtering for connections to port 443 (the typical Keylime registrar SSL port). If a single source IP generates more than 200 connections in a minute, it triggers an alert. The threshold should be tuned against the environment's baseline.
Wazuh OSSEC Rule
<rule id="120382" level="12">
<decoded_as>json</decoded_as>
<field name="event_type">flow</field>
<field name="dst_port">443</field>
<group>cve-2023-38200, dos, keylime, t1498</group>
<description>CVE-2023-38200: Possible Keylime registrar SSL connection exhaustion - high volume of connections to port 443</description>
<mitre>
<id>T1498</id>
</mitre>
<options>no_full_log</options>
<frequency>200</frequency>
<timeframe>60</timeframe>
<same_source_ip/>
<match>src_ip</match>
</rule>
Note: This Wazuh rule fires when 200+ events from the same source IP are observed within 60 seconds targeting destination port 443. The rule relies on network flow event logs being ingested into Wazuh (e.g., via Suricata or Zeek integration). Adjust the frequency threshold to match your environment's baseline traffic.
Mitigation & Patch Guidance
Patch Confidence: 2/4 (CLAIMED — single source claims a patch exists; no version, commit, or advisory confirmed. Do NOT rely solely on patching without independent verification.)
1. Immediate Mitigations (No Patch Available)
- Restrict Network Access: Limit exposure of the Keylime registrar SSL port to trusted networks only. Place the registrar behind a firewall or security group that permits connections only from known Keylime agent subnets.
- Deploy Connection Throttling at the Network Layer: Use a reverse proxy or load balancer (HAProxy, Nginx, or cloud WAF) in front of the registrar to enforce:
- Maximum concurrent connections per source IP (e.g., 10–50)
- Connection rate limiting (e.g., 10 new connections per second per IP)
- TLS handshake timeouts (e.g., 10 seconds) to drop slow/half-open connections
- Enable TLS Handshake Timeouts: Replace the registrar's blocking SSL handling with a termination proxy that aggressively times out incomplete handshakes. This prevents attackers from holding connection slots indefinitely.
- Apply IP Reputation and Abuse Filtering: Block known Tor exit nodes, cloud provider ranges, or geographies that do not correspond to legitimate deployment regions.
2. Patch/Upgrade Steps
- Verify Patch Availability: Contact Red Hat or the Keylime project maintainers to confirm the reported patch. Request the exact fixed version or commit hash. The CNA claim is not independently verified — do not assume a patch exists without confirmation.
- Upgrade When Confirmed: Once a patched version is identified, upgrade the Keylime registrar to the fixed release in a staging environment first. Test attestation workflows thoroughly before production rollout.
- Monitor the Keylime GitHub repository and mailing list for official security advisories containing the fixed version number.
3. Long-Term Hardening
- Assume the Registrar Is Untrusted-Network Exposed: Architect Keylime deployment so the registrar is never directly internet-facing. Place it in a private subnet with strict egress/ingress rules.
- Implement Redundancy: Deploy multiple registrar instances behind a load balancer with health checking. If one instance is saturated, traffic can fail over to another.
- Add Application-Level Rate Limiting: Request or implement per-client connection quotas in the registrar application itself, rather than relying solely on network-layer protections.
- Enable TLS Session Resumption and Keep-Alives: Reduce the frequency of new connection establishment by legitimate agents to lower the baseline connection rate, making anomaly detection more effective.
- Establish Baseline Monitoring: Continuously monitor connection rate, active connection count, and handshake completion rates. Alert on deviations from the established baseline.
References
- NVD Entry — CVE-2023-38200: https://nvd.nist.gov/vuln/detail/CVE-2023-38200 (NVD description and CVSS scoring as cited in this report)
- Red Hat CVE Database: https://access.redhat.com/security/cve/CVE-2023-38200 (CNA source; contains the patch claim — verify status directly)
- Keylime Project (Official): https://keylime.dev/ (Monitor for official security advisories and patch releases; the CNA patch claim has not been independently confirmed)
- CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2023-38200 is not listed, indicating no confirmed in-the-wild exploitation as of the latest update)
- MITRE ATT&CK — T1498 (Network Denial of Service): https://attack.mitre.org/techniques/T1498/ (Relevant tactics and techniques for this vulnerability class)
Threat Actor Campaigns / Exploit-in-the-Wild Evidence: None identified. CVE-2023-38200 is not listed on the CISA KEV catalog, no public PoC or exploit code has been identified (POC_STATUS: UNKNOWN, Nuclei: NO, Exploit Code: NO), and the EPSS score of 0.01436 (70.7th percentile) indicates low but non-zero probability of exploitation. The vulnerability is likely to be incorporated into DoS botnet toolkits before being used in targeted campaigns, given the low complexity (AV:N/AC:L/PR:N/UI:N) required to exploit.