Software Security

Learning Objectives

• Deconstruct memory corruption vulnerabilities (Stack Smashing, Heap Exploitation).
• Understand advanced exploitation techniques like Return-Oriented Programming (ROP).
• Evaluate OS-level mitigations (ASLR, DEP/NX, Stack Canaries, CFI).
• Apply Secure SDLC principles, including Fuzzing and SAST/DAST integration.
• Analyze C code to identify architectural and memory flaws.

Seminar Structure (3 Hours)

• Stack and Heap Architecture
• Buffer Overflows & Return-Oriented Programming
• Task 1: Binary Exploitation Analysis

• OS Defenses (ASLR, DEP, CFI)
• Secure Development (SAST, DAST, Fuzzing)
• Task 2: Bypassing Defenses (ROP Chains)

Process Memory Architecture

When a program runs, the OS allocates virtual memory, typically divided into:

• Text Segment: Executable machine instructions (Read-Only).
• Data/BSS Segments: Initialized and uninitialized global variables.
• Heap: Dynamically allocated memory (e.g., malloc()). Grows upward.
• Stack: Local variables, function parameters, and return addresses. Grows downward (in x86/x64).

Stack Smashing (Buffer Overflow)

Occurs when data written to a buffer exceeds its allocated boundary, overwriting adjacent memory locations.

• When a function is called, the CPU pushes the address of the next instruction onto the Stack.
• If an attacker overflows a local variable, they can overwrite this return address.
• When the function exits (ret), the CPU jumps to the attacker's injected address (e.g., pointing to malicious shellcode).

Return-Oriented Programming (ROP)

What if the attacker cannot inject shellcode into the stack because the stack is marked as non-executable?

• ROP: The attacker searches the existing executable (and linked libraries like libc) for small sequences of instructions ending in a ret. These are called Gadgets.
• Instead of injecting code, the attacker overflows the stack with a chain of return addresses pointing to these gadgets.
• The CPU executes the existing code in an order defined by the attacker to achieve malicious goals (e.g., calling system("/bin/sh")).

Introduction to Task 1

To defend against memory corruption, you must be able to think like a reverse engineer and understand how data maps to the stack.

Task 1: Binary Exploitation Analysis

OS-Level Mitigations

Modern operating systems employ deep architectural defenses against exploitation.

• DEP/NX (Data Execution Prevention / No-eXecute): Marks memory regions (like the Stack and Heap) as non-executable. Stops traditional shellcode injection.
• ASLR (Address Space Layout Randomization): Randomizes the memory locations of the stack, heap, and libraries (like libc) every time the program runs. Prevents attackers from hardcoding return addresses.
• Stack Canaries: A random value placed between local variables and the return address. Checked before the function returns; if altered, the program crashes to prevent hijacking.

Control-Flow Integrity (CFI)

An advanced compiler-level mitigation against ROP and indirect pointer overwrites.

Secure SDLC & Automated Testing

Mitigations fail; preventing the vulnerability in the code is always the priority.

• SAST (Static Application Security Testing): Analyzes source code for flaws (e.g., finding strcpy) without executing it. Fast, but prone to false positives.
• DAST (Dynamic Application Security Testing): Interacts with the running application to find flaws (e.g., injecting SQL payloads). Cannot see internal code.
• Fuzzing: Feeding massive amounts of malformed, unexpected, or random data to a program's inputs to deliberately cause a crash, revealing memory corruption bugs.

Introduction to Task 2

Security is an arms race. When defenders introduced DEP/NX, attackers invented ROP. When defenders introduced ASLR, attackers invented Info Leaks.

Task 2: Bypassing Defenses (ROP Chains)