heap 0

Description

Menu overview

• 1. Print heap (shows your buffer).
• 2. Write to buffer (overflow opportunity).
• 3. Print safe_var (the target we'll zero out).
• 4. Print flag (only works once safe_var == 0).

Solution

1. Step 1Measure the gap
   Reading heap0.c reveals your buffer is allocated just before safe_var, with 32 bytes between them. Overflowing with exactly 32 characters will zero safe_var.
   Learn more

   The heap is the region of memory used for dynamic allocations (via malloc, calloc, new). Unlike the stack (which is managed automatically), heap memory is manually allocated and freed by the programmer. The C runtime maintains the heap as a series of chunks, where each chunk has a header storing its size and status, followed by the user data.

   When two heap allocations happen in sequence (like malloc(32) for the buffer followed by malloc(sizeof(safe_var))), the allocator typically places them in adjacent memory. This adjacency is the key insight: overflowing the first allocation can corrupt the second. This is fundamentally the same as a stack buffer overflow, but on the heap - hence the challenge's question "Are overflows just a stack concern?"

   The 32-byte gap tells you exactly how many bytes to write before reaching safe_var. In a real exploit, you might not have the source code and would need to determine this offset experimentally (by writing increasing amounts of data and observing when safe_var changes) or by reading the binary in a disassembler to find the allocation sizes.

   Heap layout can vary between systems due to alignment, debug allocators, and allocator implementation differences. Always test your exploit on the same environment as the target - a heap overflow that works locally may fail remotely if the heap layout differs.

2. Step 2Trigger the overflow
   Use option 2 and enter 32 characters (e.g., A repeated 32 times). The trailing null terminator from fgets lands in safe_var, clearing it.

   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

   Copied!
   Learn more

   The null terminator trick works because fgets() always appends a null byte (\0) after the input. If you write exactly 32 characters, fgets writes 32 bytes of input followed by a null byte - 33 bytes total. The 33rd byte (the null) lands at the first byte of safe_var, zeroing it.

   This is subtly different from classic buffer overflows: you're not trying to overwrite a return address or function pointer with a useful value. You're just relying on the incidental null terminator to zero the adjacent variable. This makes it a "gentler" overflow - no need for shellcode or ROP chains, just careful byte counting.

   The choice of A as filler is a CTF convention. The hex value of A is 0x41, making filled buffers visually distinctive in hex dumps (you'll see rows of 41 41 41 41...). This makes it easy to spot exactly where your input landed in memory. Similarly, B (0x42) is used for a second buffer when you need to distinguish two inputs.

   fgets() is considered safer than gets() precisely because it takes a size argument and won't read more than the specified number of bytes. However, "won't overflow the specified buffer" is not the same as "won't overflow adjacent heap objects" - if the size argument is wrong or the heap layout puts sensitive data right after the buffer, even fgets-limited input can be dangerous.

3. Step 3Print the flag
   Now that safe_var is zeroed, option 4 succeeds. The program checks the guard variable before revealing the flag.

   nc tethys.picoctf.net <PORT_FROM_INSTANCE>

   Copied!
   Write 32 bytes via option 2, then select option 4 to read the flag.
   Learn more

   A guard variable (like safe_var) is a program variable whose value controls access to sensitive functionality. The pattern of "check a guard, then reveal a secret" is the simplest form of access control logic. In real applications, guard variables might represent authentication state, license flags, or feature enable/disable conditions.

   This challenge shows why memory safety is critical: if an attacker can corrupt any memory - not just return addresses - they can subvert the program's security logic. A guard variable that should only be modifiable through legitimate authentication can be bypassed entirely if the attacker can write to its memory address through an overflow.

   Heap overflows are used in real-world exploits to corrupt heap metadata (the allocator's bookkeeping structures), function pointers stored on the heap, C++ vtable pointers, and security-sensitive flags - exactly as in this challenge. High-profile vulnerabilities like HeartBleed (OpenSSL) and many browser exploits involve heap corruption as a key step.

   Languages with automatic memory management (Java, Python, Go, Rust) eliminate most heap overflow vulnerabilities because array bounds are checked at runtime and manual memory management is restricted or absent. This is why memory-safe languages are increasingly recommended for security-critical code.

Flag

picoCTF{my_first_heap_overflow_0c47...}

Zeroing safe_var unlocks option 4, printing the flag above.