🕸 Advanced Buffer Overflows (BOFs)

🐍 Series: Open Deception Framework (ODF) | Arc: 3

Series 1, Blog 3: From SEH Exploitation to Pwntools Automation.

💥

A Long-Term Exploit Backbone

When people first learn about hacking, “buffer overflow” often sounds like an outdated relic from the 1990s - but advanced buffer overflows are still the backbone of many real-world exploits. A buffer is just a small space in memory where a program stores temporary data: username, password, or message. A buffer overflow happens when that space is too small for the data the user provides, and instead of rejecting the input, the program allows it to spill over into nearby memory. If an attacker is clever, that “spill” can be used to overwrite instructions, redirect execution, or inject malicious code.

Over the years, operating systems and compilers have added defences to make exploitation harder:

• Address Space Layout Randomisation (ASLR) Randomises memory locations, so attackers can’t easily guess where to jump.

  Imagine you want to break into a house, but every time you come back, all the doors and windows have been moved to random places. That’s what ASLR does to a program’s memory. Normally, when a program runs, certain parts of its memory ( libraries, functions, and stack) always appear at the same addresses. Attackers could take advantage of this predictability by “jumping” directly to those locations during an exploit. ASLR changes that game by randomising where things are loaded each time the program starts. Now the attacker can’t easily guess the correct address to hijack. To succeed, they’d need either:

  • An information leak (finding a way to reveal where something is located), or

  • A partial overwrite trick (only overwriting the lower 1–2 bytes of an address, since the higher bytes may still be predictable).

  In short, ASLR makes memory a moving target, but not an impossible one.

• Data Execution Prevention (DEP) Stops injected data from being executed as code.

  Think of DEP like a security guard that checks whether a room in memory is allowed to host a party. Traditionally, attackers would just dump shellcode (malicious instructions) into a writable space (like the stack) and then redirect execution to it.

  DEP prevents that by marking certain regions of memory as non-executable. Data can live there, but the CPU won’t run it as instructions. For example:

  • The stack Writable but non-executable

  • Heap Writable but non-executable

  • Code segment Executable but not writable

  This breaks the classic “stack smash and jump” exploit, but attackers adapted with techniques such as:

  • Return-to-libc Instead of injecting new code, call existing functions (like system("/bin/sh")) in loaded libraries.

  • Return-Oriented Programming ROP chains Stitching together small chunks of existing code, each ending in a return instruction, to create a “Franken-program.”

  Thus, DEP doesn’t kill exploitation, it just forces it to become more creative.

• Stack Canaries Small values placed next to return addresses on the stack - if an overflow overwrites them, the program notices and aborts.

  A “canary in a coal mine” was a small bird miners used to detect toxic gases. If the bird died, miners knew something was wrong. Stack canaries serve the same purpose for programs. When a function is called, the system places a secret random value (the canary) just before the function’s return address on the stack. If an attacker overflows the buffer and tries to overwrite the return address, the canary value also gets overwritten.

  Before the function returns, the program checks:

  • If the canary is unchanged Safe to continue.

  • If the canary is corrupted Program aborts immediately.

  This makes simple buffer overflows much harder, because you can’t overwrite the return address without also tampering with the canary.

  The catch? If an attacker finds a way to leak the canary value, they can overwrite it with the correct one and still succeed.

⚒️ TL;DR Exploitation Tools Summary

• 32/64-bit BOFs Exploits differ between architectures. 32-bit is often easier (linear memory, smaller addresses), while 64-bit introduces calling conventions and larger addresses.

• SEH exploitation Overwriting the Structured Exception Handler on Windows to hijack execution when a crash occurs.

• Egghunter payloads Tiny shellcode that hunts through memory for a bigger payload tagged with an “egg” marker.

• ASLR bypass via partial overwrites Defeating Address Space Layout Randomisation by only overwriting part of a pointer (lower 2 bytes), since higher bytes may remain predictable.

• Return-to-libc Instead of injecting shellcode, re-use existing library functions (like system("/bin/sh")).

• Pwntools A Python framework that automates exploit development and shellcode staging.

❤️‍🔥 Topical vulnerabilities

1. CVE-2025-32756 Critical Stack-Based Buffer Overflow in Fortinet Products

   In May 2025, Fortinet disclosed a stack-based buffer overflow affecting several of its products - FortiVoice, FortiRecorder, FortiNDR, FortiMail, and FortiCamera. The flaw impacts the administrative API and enables unauthenticated remote code execution, making it a high-stakes issue. With a CVSS score of 9.6, it has been actively exploited in the wild, prompting urgent patches and inclusion in CISA’s Known Exploited Vulnerabilities (KEV) catalog.

2. CVE-2025-32706 Heap-Based Buffer Overflow in Windows CLFS Driver

   Another major vulnerability surfaced in May 2025, this time within the Windows Common Log File System (CLFS) driver. The heap-based buffer overflow allows a local attacker to escalate privileges—potentially reaching SYSTEM-level access. This vulnerability has also been observed being exploited, and was added to CISA’s KEV list due to its severity and real-world impact.

3. CVE-2025-9355 Stack-Based Buffer Overflow in Linksys RE-Series Range Extenders

   Very recently (August 2025), CVE‑2025‑9355 was disclosed in Linksys RE-series Wi‑Fi range extenders, including models like RE6250, RE6300, RE6500, RE7000, and RE9000. The flaw resides in the device’s web interface (/goform/scheduleAdd endpoint), where improper validation of a ruleName parameter triggers a stack-based buffer overflow. No authentication is required to exploit it, allowing unauthenticated attackers on the network to run arbitrary code as root.

🧨

From Crash to Control

A buffer overflow is not just a programming bug - it’s a gateway into how attackers wrestle control of a system at its most fundamental level. Rarely does an adversary gain remote code execution in one clean step. Instead, they work through a chain of small, precise manipulations: first causing a crash, then steering program flow, then bypassing defenses like ASLR, DEP, or stack canaries.

Each stage might look trivial in isolation - overwriting a few bytes on the stack, redirecting an exception handler, or hunting for an “egg” marker in memory. But when linked together, these actions transform a crash into a calculated exploit, and from there into complete control of a target machine.

For defenders and learners alike, understanding this journey is critical. It reveals how:

• A simple buffer overwrite can become a stepping stone to privilege escalation.

• Exception handlers and return addresses become battlegrounds between attacker and system.

• Defensive layers (ASLR, DEP, canaries) influence the attacker’s choice of weapon; whether partial overwrites, return-to-libc, or ROP chains.

• Automation tools like Pwntools bridge the gap between theory and practice, allowing payloads to be staged, tuned, and delivered with surgical precision.

By studying buffer overflows as both science (the mechanics of memory corruption) and art (the attacker’s creative path through defences), we move beyond the myth of “old-school exploits.” Instead, we see buffer overflows for what they remain today - a living discipline, where the smallest mistake in memory handling can still cascade into system-wide compromise.

🔮 Ontology

Buffer overflow exploitation ontology defines the entities of memory (buffers, stacks, registers), attacker actions (overwrites, payload injection, ROP), and defenses (ASLR, DEP, canaries), mapping their interactions to explain how control of program flow shifts between vulnerability, exploitation, and neutralisation.

👻 Aim

To design and apply layered defence strategies that neutralise buffer overflow exploitation attempts by preventing successful control of program execution flow. This is justified because buffer overflows remain a primary entry point for privilege escalation and remote code execution in both legacy and modern systems.

🧭 Objectives

1. Strengthen memory safety by enforcing compiler-based protections (stack canaries, bounds checking, control flow integrity).

2. Harden execution environments through operating system features (ASLR, DEP, non-executable stack/heap).

3. Detect abnormal behaviour via runtime monitoring and intrusion detection (watching for crashes, SEH tampering, or suspicious ROP chains).

4. Reduce attack surface by patching vulnerable binaries and minimising unnecessary exposed services.

5. Educate defenders and testers on identifying overflow attempts during penetration testing and red-team exercises.

Think of it as the difference between accidentally crashing a program and steering its execution like a remote-controlled car.

🪄

Tactical Map

🔥 The endgame is turning a crash into command.