CVE-2024-29156

Executive Summary

CVE-2024-29156 identifies a critical information disclosure vulnerability in OpenStack Murano, specifically within its MuranoPL extension to the YAQL (Yet Another Query Language) language. When using YAQL versions prior to 3.0.0, the MuranoPL extension fails to properly sanitize the supplied environment, allowing an attacker to leak sensitive service account information. This vulnerability could lead to the exposure of credentials, tokens, or other secrets used by the Murano service, potentially enabling lateral movement or privilege escalation within an OpenStack deployment. The vulnerability is currently unpatched, and no public exploit code is available.

Supply Chain & Package Security

This vulnerability is tied to the YAQL library, a Python package used for querying and filtering data. The insecure behavior is introduced when YAQL < 3.0.0 is used in conjunction with MuranoPL. Organizations using OpenStack Murano should verify their YAQL version and consider upgrading to YAQL 3.0.0 or later, which includes the necessary sanitization. The OpenStack Murano project itself is also affected, and a patch for Murano may be required to fully remediate the issue.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or unassigned. Based on the vulnerability description, a reasonable assessment would be:

• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely via YAQL queries.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – An attacker needs some level of access to the Murano service.
• User Interaction (UI): None (N) – No user action is needed.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Sensitive service account information is leaked.
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No denial of service.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Estimated Score: 6.5 (Medium)

Threat Level: Medium. While the vulnerability is not remotely exploitable without some access, the potential leakage of service account credentials could lead to significant compromise.

Deep Dive & Mechanics

The vulnerability resides in the MuranoPL extension, which is a domain-specific language (DSL) used within OpenStack Murano to define application packages and workflows. MuranoPL extends YAQL to allow dynamic querying of environment variables and configuration data.

Root Cause: The MuranoPL extension does not sanitize the environment supplied to YAQL expressions. When YAQL < 3.0.0 is used, it lacks built-in protections against accessing sensitive internal variables. An attacker who can craft a YAQL expression (e.g., through a Murano package or API call) can query environment variables that contain service account credentials, such as OS_PASSWORD, OS_AUTH_TOKEN, or other secrets stored in the environment.

Attack Flow:

1. An attacker gains access to the Murano service (e.g., through a compromised tenant account or a vulnerable API endpoint).
2. The attacker submits a malicious MuranoPL package or a YAQL query that includes expressions like $.environment.OS_PASSWORD or $.env.SECRET_KEY.
3. The MuranoPL extension processes the query without sanitization, returning the value of the requested environment variable.
4. The attacker receives the sensitive information, which can then be used to authenticate as the service account and access other OpenStack services.

Affected Components:

• OpenStack Murano (all versions up to 16.0.0)
• YAQL library (versions prior to 3.0.0)

Vulnerable vs. Patched Code

Vulnerable Code (YAQL < 3.0.0): In YAQL, the environment is passed directly to the expression evaluator without restrictions. For example, in the YAQL engine, the evaluate function might look like:

def evaluate(expression, data, environment):
    # No sanitization of environment
    return engine.evaluate(expression, data, environment)

This allows access to any key in the environment dictionary.

Patched Code (YAQL >= 3.0.0): YAQL 3.0.0 introduced a sanitization mechanism that restricts access to environment variables. The patched code might include a whitelist of allowed keys or a function to filter out sensitive variables:

def evaluate(expression, data, environment):
    sanitized_env = {k: v for k, v in environment.items() if not k.startswith('OS_')}
    return engine.evaluate(expression, data, sanitized_env)

Additionally, MuranoPL should be updated to not pass the full environment to YAQL, but only a subset of safe variables.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to a Murano service endpoint (e.g., https://murano.example.com:8082)
• Valid credentials for a tenant that can deploy Murano packages

Exploitation Steps:

1. Create a malicious MuranoPL package that includes a YAQL expression to leak environment variables.
2. Upload the package to the Murano service.
3. Trigger the package execution, which will evaluate the YAQL expression and return the sensitive data.

Example Malicious Package (YAML):

name: malicious-package
version: 1.0.0
description: Leak environment variables
classes:
  - name: LeakEnv
    methods:
      - name: execute
        body: |
          return $.environment.OS_PASSWORD

Alternative Exploit via API: If the Murano API allows direct YAQL queries, an attacker could send a crafted request:

curl -X POST https://murano.example.com:8082/v1/environments \
  -H "X-Auth-Token: <token>" \
  -d '{"expression": "$.environment.OS_PASSWORD"}'

Blue Team (Detection & Defense)

Detection:

• Monitor Murano API logs for unusual YAQL expressions that reference environment variables (e.g., $.environment, $.env, OS_).
• Use network monitoring to detect outbound connections from the Murano service to unexpected destinations (potential data exfiltration).
• Implement application-level logging to capture all YAQL queries and their results.

Defense:

• Upgrade YAQL to version 3.0.0 or later.
• Apply any available patches for OpenStack Murano.
• Restrict access to the Murano API to only trusted tenants and users.
• Use a Web Application Firewall (WAF) to block requests containing suspicious YAQL patterns.
• Implement environment variable whitelisting in MuranoPL.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual API requests to Murano endpoints containing YAQL expressions with $.environment or $.env.
  • Outbound connections from the Murano service to external IP addresses (potential data exfiltration).

• File IOCs:

  • MuranoPL packages containing YAQL expressions that reference environment variables.
  • Log entries showing successful retrieval of environment variables (e.g., OS_PASSWORD returned in response).

• System IOCs:

  • Unauthorized access to OpenStack service accounts (e.g., using leaked credentials).
  • Anomalous API calls to other OpenStack services (e.g., Nova, Cinder) using the leaked credentials.

Detection Engineering

YARA Rule

rule Detect_Malicious_MuranoPL_Package {
    meta:
        description = "Detects MuranoPL packages containing YAQL expressions that leak environment variables"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-29156"
    strings:
        $s1 = "$.environment" ascii wide nocase
        $s2 = "$.env" ascii wide nocase
        $s3 = "OS_" ascii wide nocase
    condition:
        any of ($s1, $s2) and $s3
}

Sigma Rule

title: Suspicious YAQL Expression in Murano API Request
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects API requests to Murano containing YAQL expressions that may attempt to leak environment variables
author: Valters IT
date: 2024-01-01
logsource:
    category: application
    product: openstack
    service: murano
detection:
    selection:
        http.request.body|contains:
            - "$.environment"
            - "$.env"
            - "OS_"
    condition: selection
falsepositives:
    - Legitimate use of environment variables in MuranoPL packages (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-29156 - Potential YAQL Environment Variable Leak in Murano";
    flow:to_server,established;
    content:"$.environment"; http_client_body; nocase;
    content:"OS_"; http_client_body; nocase;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade YAQL: Ensure YAQL is version 3.0.0 or later. This is the primary fix for the underlying library.
2. Patch Murano: Check for any available patches for OpenStack Murano that address this vulnerability. If none exist, consider implementing a workaround.
3. Restrict Access: Limit access to the Murano API to only trusted tenants and users. Use role-based access control (RBAC) to minimize exposure.

Long-Term Mitigations:

• Environment Variable Whitelisting: Modify MuranoPL to only pass a whitelist of safe environment variables to YAQL.
• Input Validation: Implement strict input validation for all YAQL expressions submitted to the Murano service.
• Monitoring: Deploy the detection rules provided above to monitor for exploitation attempts.
• Audit: Regularly audit MuranoPL packages and API logs for suspicious activity.

Workaround (if patching is not possible):

• Disable the MuranoPL extension or restrict its use to only trusted administrators.
• Use a reverse proxy to filter out requests containing suspicious YAQL patterns.

Valters IT
Securing OpenStack Deployments