Buffer Overflow Exploitation Concepts

The stack grows downward (toward lower memory addresses). The stack pointer (ESP/RSP) points to the top of the stack. The base pointer (EBP/RBP) is used as a reference point for accessing parameters and locals.

void vulnerable(char *input) {
    char buffer[64];
    strcpy(buffer, input); // no bounds checking
}

When vulnerable() is called, the stack frame looks like this (low to high addresses): - buffer[0..63] (64 bytes) - saved EBP (4 bytes on x86, 8 bytes on x64) - return address (4 or 8 bytes) - parameters (optional)

The strcpy() function copies input into buffer without checking length. If input is longer than 64 bytes, it overwrites the saved EBP, then the return address, and beyond. By carefully crafting the input, an attacker can overwrite the return address with a pointer to malicious code (shellcode) placed in the buffer or elsewhere, achieving arbitrary code execution.

Buffer overflows are a classic vulnerability that still appears in enterprise environments, especially in legacy systems, embedded devices, and custom applications. For example, a penetration tester might encounter a buffer overflow in a network-attached storage (NAS) device's web interface. The device runs a stripped-down Linux with an old HTTP server that uses sprintf() to log user input into a fixed buffer. By sending a long HTTP request, the tester can overflow the buffer, overwrite the return address, and execute a reverse shell to gain root access. This is a common scenario in IoT pentesting.

Another real-world example is exploiting a buffer overflow in a corporate VPN client. The client might have a vulnerable strcpy() in its certificate parsing logic. A malicious VPN server sends a crafted certificate with a long Common Name field. When the client parses it, the overflow corrupts memory, allowing remote code execution on the endpoint. This attack could be used in red team engagements to gain initial access.

In production, developers often mitigate overflows by using safe functions (strncpy, snprintf) or compiler protections (stack canaries, ASLR, DEP). However, many embedded systems have these protections disabled due to performance constraints. Penetration testers must be able to identify unprotected binaries using tools like checksec (e.g., checksec --file=binary). Common misconfigurations include compiling without -fstack-protector, disabling ASLR via personality() syscall, or marking the stack as executable (e.g., -z execstack). When these protections are absent, exploitation is straightforward. When present, the tester must use advanced techniques like ROP or ret2libc.

Performance considerations: Exploits may fail due to environmental differences (e.g., different libc versions, ASLR entropy). Testers often use a staged payload: a small first-stage shellcode that downloads a larger second-stage. This reduces size constraints and improves reliability. The PT0-002 exam expects you to understand these practical challenges and how to overcome them.