CVE-2022-1053

9.1 CRITICAL

📋 TL;DR

This vulnerability in Keylime allows an attacker to bypass TPM-based hardware attestation by using mismatched attestation key (AK) and endorsement key (EK) pairs. Attackers can present a real TPM's EK for initial validation but then use a software TPM's AK for integrity checks, breaking the entire chain of trust. This affects any system using Keylime for remote attestation without proper validation of registrar data consistency.

💻 Affected Systems

Products:
  • Keylime
Versions: All versions before commit bd5de712acdd77860e7dc58969181e16c7a8dc5d
Operating Systems: Linux
Default Config Vulnerable: ⚠️ Yes
Notes: Affects Keylime deployments using TPM-based remote attestation. The vulnerability is present in default configurations when using the agent registration process.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Complete compromise of remote attestation system allowing attackers to spoof trusted hardware attestation, potentially enabling supply chain attacks, unauthorized access to secure systems, and bypassing hardware-based security controls.

🟠

Likely Case

Attacker gains ability to present untrusted systems as trusted hardware, potentially allowing unauthorized access to cloud infrastructure, container environments, or secure boot processes relying on Keylime attestation.

🟢

If Mitigated

With proper network segmentation and additional authentication layers, impact limited to specific attestation systems, though chain of trust remains broken for affected components.

🌐 Internet-Facing: HIGH
🏢 Internal Only: HIGH

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ✅ No
Complexity: MEDIUM

Exploitation requires ability to interact with Keylime agent registration process and access to both hardware and software TPM components. The advisory provides technical details but no public exploit code.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Commit bd5de712acdd77860e7dc58969181e16c7a8dc5d and later

Vendor Advisory: https://github.com/keylime/keylime/security/advisories/GHSA-jf66-3q76-h5p5

Restart Required: Yes

Instructions:

1. Update Keylime to version containing commit bd5de712acdd77860e7dc58969181e16c7a8dc5d or later. 2. Restart all Keylime services (verifier, registrar, tenant). 3. Re-register all agents with the updated system.

🔧 Temporary Workarounds

Disable agent auto-registration

linux

Manually validate and register agents instead of using automatic registration to ensure proper AK/EK pair validation

🧯 If You Can't Patch

  • Implement network segmentation to isolate Keylime components from untrusted networks
  • Add additional authentication/authorization layers before granting access based on Keylime attestation results

🔍 How to Verify

Check if Vulnerable:

Check Keylime version: if using code before commit bd5de712acdd77860e7dc58969181e16c7a8dc5d, system is vulnerable

Check Version:

git log --oneline -1 (in Keylime source directory) or check package version

Verify Fix Applied:

Verify Keylime installation includes commit bd5de712acdd77860e7dc58969181e16c7a8dc5d and test agent registration with mismatched AK/EK pairs (should fail)

📡 Detection & Monitoring

Log Indicators:

  • Multiple registration attempts from same agent with different AK values
  • Agent registration success without proper regcount validation

Network Indicators:

  • Unusual TPM attestation traffic patterns
  • Multiple AK presentations from single endpoint

SIEM Query:

source="keylime" AND ("agent registration" OR "attestation") AND (ak_changed OR regcount!=1)

🔗 References

📤 Share & Export