CVE-2024-23949

Executive Summary

CVE-2024-23949 is a high-severity (CVSS 8.8) out-of-bounds write vulnerability in the libigl library, version 2.5.0. The flaw resides in the igl::MshLoader::parse_node_field function, which improperly validates array indices when parsing specially crafted ASCII .msh files. An attacker can exploit this by providing a malicious .msh file, leading to memory corruption and potential arbitrary code execution. The vulnerability is currently unpatched, and no public exploit code or proof-of-concept is available. The EPSS score is 0.0%, indicating low exploitation activity in the wild.

Supply Chain & Package Security

This vulnerability affects the libigl library, which is distributed as a C++ header-only library and is commonly used in geometry processing and scientific computing applications. It is not an NPM, PyPI, Go, or Ruby package, but it is a critical dependency for many downstream projects. Users should monitor for updates and apply patches as soon as they become available.

CVSS Breakdown & Threat Level

• CVSS Score: 8.8 (High)
• Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Attack Vector: Local (requires user interaction to open a malicious file)
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: Required
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: High

The threat level is high due to the potential for arbitrary code execution, though exploitation requires user interaction.

Deep Dive & Mechanics

The vulnerability is an out-of-bounds write in the igl::MshLoader::parse_node_field function. When parsing an ASCII .msh file, the function reads node field data and writes it into an array. The array index validation is insufficient, allowing an attacker to specify indices that exceed the allocated buffer size. This can lead to memory corruption, potentially overwriting adjacent data structures or executing arbitrary code.

The root cause is the lack of bounds checking on the index used to access the array. The function likely reads an index from the file and uses it directly without verifying it is within the valid range.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is in libigl version 2.5.0. The specific function is igl::MshLoader::parse_node_field. The vulnerable code likely looks like:

void MshLoader::parse_node_field(std::ifstream &in) {
    int index;
    in >> index;
    // No bounds check
    node_field_data[index] = value;
}

A patched version would include a bounds check:

void MshLoader::parse_node_field(std::ifstream &in) {
    int index;
    in >> index;
    if (index < 0 || index >= node_field_data.size()) {
        throw std::runtime_error("Index out of bounds");
    }
    node_field_data[index] = value;
}

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would craft a malicious .msh file with an out-of-bounds index in the node field section. The file would be sent to a victim who uses a vulnerable version of libigl to open it. The exploit could lead to arbitrary code execution if the attacker can control the overwritten memory.

Lab Setup:

1. Install libigl v2.5.0.
2. Create a malicious .msh file with a crafted node field index.
3. Use a debugger to observe the out-of-bounds write.
4. Develop a payload to achieve code execution.

Example malicious .msh file structure:

$MeshFormat
2.2 0 8
$EndMeshFormat
$NodeData
1
"test"
1
0.0
1
0 1.0 2.0 3.0
$EndNodeData

Blue Team

Detection:

• Monitor for processes that open .msh files and exhibit abnormal memory access patterns.
• Use memory corruption detection tools (e.g., AddressSanitizer) during development.

Mitigation:

• Isolate applications that process .msh files in sandboxed environments.
• Implement input validation and bounds checking in custom parsers.

Indicators of Compromise (IOCs)

• File Hashes: (No known samples)
• Network Indicators: None (local file-based exploit)
• Behavioral Indicators: Abnormal memory access patterns in processes using libigl v2.5.0.

Detection Engineering

YARA Rule

rule CVE_2024_23949_libigl_msh {
    meta:
        description = "Detects malicious .msh files targeting CVE-2024-23949"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-23949"
    strings:
        $header = "$MeshFormat"
        $node_data = "$NodeData"
        $ascii = "2.2 0 8"
    condition:
        $header at 0 and $node_data and $ascii
}

Sigma Rule

title: CVE-2024-23949 Exploitation Attempt
id: cve-2024-23949
status: experimental
description: Detects potential exploitation of CVE-2024-23949 via malicious .msh files
author: Valters IT
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\your_app.exe'
        CommandLine|contains: '.msh'
    condition: selection
falsepositives:
    - Legitimate use of .msh files
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2024-23949 Malicious .msh File Transfer"; flow:to_client; fileext:"msh"; content:"$MeshFormat"; content:"$NodeData"; sid:1000001; rev:1;)

Remediation & Mitigation

• Immediate: Avoid opening .msh files from untrusted sources. Use input validation and bounds checking in custom parsers.
• Long-term: Apply patches from libigl when available. Consider using memory-safe languages or libraries for parsing untrusted data.
• Monitoring: Implement detection rules (YARA, Sigma, Suricata) to identify malicious .msh files.

Valters IT
Securing Digital Frontiers