CVE-2025-58356

Executive Summary

CVE-2025-58356 is a critical vulnerability in the cryptsetup library, specifically affecting versions prior to 2.24.0, and exploited within the Constellation Confidential Kubernetes (CVM) environment. The flaw lies in the unsafe handling of null keyslot algorithms (specifically cipher_null-ecb) in LUKS2-formatted volumes. When Constellation’s CVM image uses crypt_activate_by_passphrase to open an encrypted storage device, a successful activation with a null cipher does not indicate actual encryption. An attacker with local administrative access to the CVM can craft a LUKS2 header that uses cipher_null-ecb in the keyslot encryption field. The system will report the volume as successfully opened and treat it as confidential, while the underlying data is stored in plaintext. This allows an attacker to read, modify, or exfiltrate sensitive data that should be protected by disk encryption.

The vulnerability is particularly severe in the context of Confidential Computing, where the entire premise is that data is encrypted at rest and in use. A successful exploit completely undermines the confidentiality guarantees of the Constellation platform.

Supply Chain & Package Security

This vulnerability is not in a package manager ecosystem (NPM, PyPI, Go, Ruby) but in a system-level library (cryptsetup). The supply chain risk is indirect: if an organization uses a container image or VM image that bundles a vulnerable version of cryptsetup (e.g., from a base OS image), they are at risk. The fix is to update the cryptsetup package in the base image to version 2.24.0 or later.

CVSS Breakdown & Threat Level

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

• Attack Vector (AV): Local (L) – The attacker must have local access to the CVM.
• Attack Complexity (AC): Low (L) – No special conditions beyond local access.
• Privileges Required (PR): High (H) – The attacker needs administrative (root) privileges on the CVM.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Changed (C) – The vulnerability impacts resources beyond the vulnerable component (the entire confidential workload).
• Confidentiality (C): High (H) – All data on the volume is exposed.
• Integrity (I): High (H) – Data can be modified.
• Availability (A): High (H) – Data can be deleted or corrupted.

Threat Level: Critical. While the attack requires local admin access, in a multi-tenant or shared infrastructure environment, a compromised or malicious admin could exploit this to break the confidentiality of all workloads on the node.

Deep Dive & Mechanics

The vulnerability is in the cryptsetup library’s handling of LUKS2 keyslot algorithms. LUKS2 allows multiple keyslots, each with its own encryption algorithm for the key material. The cipher_null-ecb algorithm is a null cipher that performs no encryption. In a properly secured system, cryptsetup should reject any keyslot that uses a null cipher.

In versions prior to 2.24.0, crypt_activate_by_passphrase does not check for the null cipher. When it successfully opens a volume using a null cipher keyslot, it returns success. The calling code (in this case, Constellation’s CVM image) then assumes the volume is encrypted and treats it as confidential. However, the actual data on the disk is stored in plaintext.

Attack Flow:

1. Attacker gains root access to the CVM (e.g., via a separate vulnerability or insider threat).
2. Attacker creates a LUKS2 header on a new or existing volume, using cipher_null-ecb for the keyslot encryption.
3. Attacker places sensitive data on this volume.
4. The CVM’s initialization code calls crypt_activate_by_passphrase with the correct passphrase.
5. cryptsetup (vulnerable) opens the volume and returns success.
6. The CVM treats the volume as encrypted and confidential, but the data is actually in plaintext.
7. Attacker can read the data directly from the disk (e.g., via /dev/mapper/ or raw block device access).

Vulnerable vs. Patched Code

Vulnerable Code (cryptsetup < 2.24.0):

// In libcryptsetup, crypt_activate_by_passphrase function
// No check for cipher_null-ecb in keyslot algorithm
int crypt_activate_by_passphrase(struct crypt_device *cd, ...) {
    // ... open keyslot, decrypt key material
    // If decryption succeeds (even with null cipher), return success
    return 0; // Success
}

Patched Code (cryptsetup >= 2.24.0):

// In libcryptsetup, crypt_activate_by_passphrase function
// Added check for null cipher
int crypt_activate_by_passphrase(struct crypt_device *cd, ...) {
    // ... open keyslot, check algorithm
    if (keyslot_algorithm_is_null(cd, keyslot)) {
        log_error(cd, "Keyslot uses null cipher, rejecting.");
        return -EINVAL; // Error
    }
    // ... decrypt key material
    return 0; // Success only if real encryption
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Local root access on a Constellation CVM running a vulnerable cryptsetup (< 2.24.0).
• Ability to create or modify a LUKS2 volume.

Steps:

1. Create a LUKS2 volume with a null cipher keyslot:

   # Create a 1GB file for the volume
   dd if=/dev/zero of=/tmp/evil_volume.img bs=1M count=1024
   # Format with LUKS2 using cipher_null-ecb for keyslot
   # Note: This requires a patched version of cryptsetup to create, but the vulnerable version can still open it.
   # For demonstration, we assume the attacker has a tool to craft the header.
   # Alternatively, use a pre-crafted header.
   

2. Place sensitive data on the volume:

   # Open the volume (vulnerable cryptsetup will succeed)
   cryptsetup open --type luks2 /tmp/evil_volume.img evil_volume
   # Write plaintext data
   echo "Sensitive data" > /dev/mapper/evil_volume
   # Close
   cryptsetup close evil_volume
   

3. The CVM’s initialization code will open the volume and treat it as encrypted. The attacker can then read the data directly from the block device.

Proof of Concept (No public exploit available):

# Simulate the vulnerable behavior
# Assume the volume is already crafted
cryptsetup open --type luks2 /tmp/evil_volume.img evil_volume
# Check if it's actually encrypted (it won't be)
cryptsetup status evil_volume
# Read plaintext data
dd if=/dev/mapper/evil_volume bs=512 count=1 | strings

Blue Team (Detection & Defense)

Detection:

• Monitor for LUKS2 volumes with cipher_null-ecb in their keyslot algorithm.
• Use cryptsetup luksDump to inspect volumes:

  cryptsetup luksDump /dev/sdX | grep -i cipher
  

• Look for cipher_null-ecb in the output.

Defense:

• Immediately upgrade cryptsetup to version 2.24.0 or later.
• Implement a pre-flight check in the CVM initialization code to verify that the keyslot algorithm is not null.
• Use integrity monitoring to detect unauthorized modifications to LUKS headers.

Indicators of Compromise (IOCs)

• File System: LUKS2 volumes with cipher_null-ecb in the keyslot algorithm.
• Process: cryptsetup processes opening volumes with null cipher.
• Logs: cryptsetup logs showing successful activation of a volume with null cipher (in vulnerable versions, no error is logged).
• Network: Unusual data exfiltration from the CVM (since data is in plaintext, it can be sent over the network without decryption).

Detection Engineering

YARA Rule

rule LUKS2_Null_Cipher_Keyslot {
    meta:
        description = "Detects LUKS2 headers with cipher_null-ecb in keyslot"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-58356"
    strings:
        $luks_magic = "LUKS" ascii wide
        $null_cipher = "cipher_null-ecb" ascii wide
    condition:
        $luks_magic at 0 and $null_cipher
}

Sigma Rule

title: LUKS2 Null Cipher Keyslot Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to open a LUKS2 volume with a null cipher keyslot
author: Valters IT
date: 2025-04-10
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: 'cryptsetup'
        key: 'cipher_null-ecb'
    condition: selection
falsepositives:
    - Legitimate use of null cipher for testing (should be rare)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-58356 LUKS2 Null Cipher Exfiltration"; flow:to_server,established; content:"|4c 55 4b 53|"; offset:0; content:"cipher_null-ecb"; distance:0; within:256; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Upgrade cryptsetup to version 2.24.0 or later on all Constellation CVM images and host systems.
2. Rebuild any container images that include cryptsetup with the patched version.

Long-term:

1. Implement a validation layer in the CVM initialization code that checks the keyslot algorithm before treating a volume as encrypted.
2. Add runtime monitoring to detect LUKS2 volumes with null ciphers.
3. Conduct a security audit of all dependencies in the Constellation image.

Workaround:

• If immediate patching is not possible, manually inspect all LUKS2 volumes before use:

  cryptsetup luksDump /dev/sdX | grep -q "cipher_null-ecb" && echo "VULNERABLE"
  

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst