CVE-2024-32613 - Heap Buffer Over-Read in HDF5 Library (Through 1.14.3)

A new security vulnerability has come up in the HDF5 Library, affecting all versions through 1.14.3. Labeled CVE-2024-32613, this bug is a heap-based buffer over-read in the H5HL__fl_deserialize function (in the file H5HLcache.c). It's separate from the older CVE-2024-32612, and if you're handling scientific data, simulations, or ML pipelines that use HDF5, this one's for you.

This article breaks down what CVE-2024-32613 is, why it’s dangerous, shows a code example, gives you a basic exploit, and links to the original resources.

What Is HDF5?

HDF5 (Hierarchical Data Format version 5) is a popular file format and library used for big datasets. It’s common in scientific computing, machine learning, and high-performance computing.

What Is CVE-2024-32613?

CVE-2024-32613 is a heap-based buffer over-read—it means the program reads *more* memory than it should. This can cause the program to crash, leak information, or—in some cases—lead to code execution.

It’s located in the internal function H5HL__fl_deserialize in the C file H5HLcache.c. This function is used to deserialize free list structures for local heaps—a common element in HDF5 files.

What’s Different from CVE-2024-32612?

While CVE-2024-32612 affected a different function or code path, this bug is about buffer over-read in a different serialization routine.

> If you patched for CVE-2024-32612, you still need to patch for this!

Here’s a simplified snippet of the kind of pattern involved (from the HDF5 source)

herr_t H5HL__fl_deserialize(const uint8_t *image, size_t image_size) {
    size_t offset = ;
    uint32_t n_free_blocks;
    // ... Other vars ...

    // Suppose this reads a 4-byte header
    if(image_size < 4)
        return FAIL;

    H5MM_memcpy(&n_free_blocks, image + offset, 4);
    offset += 4;

    // Suppose each free block info is 8 bytes
    for (uint32_t i = ; i < n_free_blocks; i++) {
        if (offset + 8 > image_size) // Should check for out-of-bounds
            return FAIL; // <-- The real bug: check is insufficient or missing
        // ... read next 8 bytes ...
        offset += 8;
    }
    // ...
}

The Issue

The routine reads metadata for a number of "free blocks," but a malicious file could set n_free_blocks very large, without the buffer being big enough to hold them. If the code does not do proper boundary checking inside the loop, it reads outside image — that’s a heap buffer over-read.

Information Leakage: Over-reading may dump out heap fragments, potentially leaking secrets.

- Possible Code Execution: Less likely, but exploitable heap reads can sometimes let attackers steer the program into arbitrary behavior.

Simple Proof-of-Concept (PoC) Steps

Suppose you have a program that uses an out-of-date HDF5 library and reads a file supplied by the attacker.

PoC in Python (to generate a malicious image)

# Generate a malicious HDF5 'heap' segment with n_free_blocks set high
with open("malicious_heap.bin", "wb") as f:
    n_free_blocks = (xFFFFFFF).to_bytes(4, 'little')
    # No actual free block data follows
    f.write(n_free_blocks)
    # Not enough bytes follow, so any loop will over-read

If a vulnerable app opens this as a heap block, it may crash or leak data.

Upgrade HDF5!

- The upstream HDF5 1.14.4 and later have fixed this.

For direct users

- Download the patched version from HDFGroup releases.

The patch adds strict size checks before the loop

if (offset + n_free_blocks * 8 > image_size)
    return FAIL;

References

- CVE-2024-32613 Record at NIST NVD
- Upstream HDF5 GitHub PR fixing this (PR #2486)
- HDF5 Official

Conclusion: Who Should Care?

- Researchers and scientists: If you exchange HDF5 files with collaborators, you’re at risk of “accidental” malformed files causing crashes.

Software maintainers: Sync your dependencies.

Bottom line: Patch your HDF5 library. Heap buffer over-read bugs can be subtle but dangerous, even if they don’t sound “severe.”

*Questions or feedback? Drop them below or reach out to the HDF mailing list. Stay safe!*

Timeline

Published on: 05/14/2024 15:36:46 UTC
Last modified on: 07/03/2024 01:56:46 UTC