Listen to this Post
The vulnerability resides in OBI’s log enricher component, specifically within the `__fill_iov` function in `bpf/logenricher/logenricher.c` at line 50. For `ITER_IOVEC` iterators, this function incorrectly resolves only the first `struct iovec` entry, specifically iov_ctx.iov
</code>. The returned `iov` descriptor therefore only describes the first write segment of a `writev` call. However, the subsequent `__write` function obtains the total byte count across all segments using <code>const size_t count = BPF_CORE_READ(from, count);</code>. This total count is stored in `e->len` and is then used in two critical memory operations: `bpf_probe_read_user(e->log, e->len, iov.iov_base)` and <code>bpf_probe_write_user(iov.iov_base, zero, to_write)</code>. If the total byte count `count` exceeds the length of the first segment <code>iov.iov_len</code>, OBI will read and subsequently zero out memory located beyond the boundaries of the first write segment. This out-of-bounds (OOB) memory access can lead to corruption of adjacent application buffers, leakage of arbitrary memory into log events, and potential destabilization or crash of the instrumented process. Platform: OBI (OpenBPF Instrumentation) Version: v0.7.0 Vulnerability: Out-of-bounds (OOB) read/write in log enricher Severity: High Date: 2025-02-19 <h2 style="color: blue;">Prediction: 2025-03-14</h2> <h2 style="color: blue;">What Undercode Say:</h2> [bash] Identify the vulnerable code pattern in OBI's source grep -A 10 -B 5 "bpf_probe_read_user(e->log, e->len, iov.iov_base)" ./obi/bpf/logenricher/logenricher.c Compile the Proof-of-Concept (PoC) to trigger the vulnerability cc -O2 -o /tmp/writev-poc /tmp/writev-poc.c Run the PoC to generate a multi-segment writev stream /tmp/writev-poc > /dev/null & Attach the vulnerable OBI version to the target process PID=$(pgrep -f /tmp/writev-poc) sudo ./bin/obi --pid "$PID"
Exploit:
An attacker can exploit this vulnerability by crafting a malicious `writev` call that consists of two or more segments. The first segment is purposefully short (e.g., 8 bytes), while the second segment is large (e.g., 256 bytes). When the vulnerable OBI log enricher processes this call, it will use the total length of all segments (e.g., 264 bytes) as its copy length, but will only reference the base address of the first segment. This results in an out-of-bounds read of 256 bytes (264 - 8 = 256) into memory past the first segment. The log enricher then writes a buffer of zeros back to this out-of-bounds memory region, corrupting adjacent application data. By carefully controlling the layout of memory, an attacker could potentially read sensitive data from the process's heap or stack, and corrupt critical pointers to alter program execution.
Protection from this CVE:
Immediately upgrade to a patched version of OBI beyond v0.7.0. If upgrading is not possible, disable the log enricher or log injection features. As a short-term mitigation, instrumented applications should be audited to ensure they never pass multi-segment `writev` calls containing a short first segment to any logs. Additionally, running instrumented applications with memory safety tools like AddressSanitizer (ASan) can help detect and contain the out-of-bounds memory corruption.
Impact:
Successful exploitation leads to memory corruption and potential memory disclosure within the instrumented process. An attacker who can control or influence the `writev` calls made by a program being monitored by OBI can cause the program to write arbitrary data to or read arbitrary data from adjacent memory locations. This can result in corrupted output, leakage of sensitive information (e.g., passwords, cryptographic keys, Personally Identifiable Information) into logs, and in severe cases, process instability or crashes. The integrity and confidentiality of the instrumented application and the data it processes are at risk.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
