System Security and Buffer Overflow

Page 3

• Recap: Injection of Malicious Code

  • Generates compiler-hacking.o, uses to create login-hacked.o from
    login.c.

  • Understanding code verification processes.

Page 4

• Buffer Overflow

  • Overview of system security thoughts:

  • Goals, threat model, mechanisms, policies.

  • Majority of mechanisms are software-based, which may have bugs.

  • Security bugs lead to vulnerabilities; buffer overflow is a prominent one.

Page 5

• Buffer Overflow Context

  • Common in C/C++ due to being unsafe languages.

  • First exploit was the Morris Worm in 1988.

  • Continues to be relevant today.

  • Avoiding unsafe languages is suggested but not comprehensive; numerous changes in compilers and hardware architectures derive from it.

Page 6

• Web Server Example

  • Threat Model: Any individual who can send messages to the server.

  • Attacker's Goals:

  • Crash server, inject code, leak, or modify data.

Page 7

• Important Notes

  • Focus on Intel 32-bit architecture in Linux:

  • Little Endian, 4-byte addresses, 4GB virtual memory.

  • Use -m32 for 32-bit binaries on 64-bit machines.

Page 8

• Stack Mechanism

  • Defines the process in memory with virtual memory management.

  • Each process has own stack, heap, and code/data segments.

  • Stack is managed by the OS/compiler and are not freely accessed by applications.

  • Registers:

  • $esp</code>: Top of the stack address.</p></li><li><p><code>$ebp: Bottom of the stack address.

  • $eip: Current instruction address.

  

Page 9

• Stack Mechanism

  • The stack consists of frames for each function:

  • Top stack frame holds function info, return address, previous frame pointer.

  • Stack grows to decreasing memory indices.

Page 10

• Function Return in Stack

  • New stack pointer set to previous base pointer.

  • Pop saved base pointer and return address to new base pointer and instruction pointer.

Page 11

• Invoking Function Example

  • int func(int a, int b) uses a stack frame for local variables and return addresses.

  • Understand position within accounts and variables in call stack.

Page 12

• Returning from Function

  • See stack frames evolve as function returns and local variables are popped from the stack.

Page 13

• Buffer Overflow Example

  • void vul(char *str):

  • Implements a vulnerable buffer with a limited size; using strcpy() inserts data beyond the intended limit.

Function Return in Stack

New stack pointer set to previous base pointer. This process involves:

• Popping the saved base pointer into the new base pointer to restore the previous stack frame.

• Popping the return address into the instruction pointer that directs the flow of execution back to the caller function.

Invoking Function Example

The function declaration int func(int a, int b) is a demonstration of how local variables and return addresses are managed. Within the call stack, every invocation of a function creates a new stack frame that holds:

• Local variables.

• Return addresses allowing the program to know where to return after the function execution.

Returning from Function

As functions return:

• The stack frames evolve; local variables are removed, and the stack pointer adjusts to previous frames.

• This popping mechanism is crucial for maintaining the integrity of the program's execution flow.

Buffer Overflow Example

The code snippet:

void vul(char *str) {
 char buffer[16];
 strcpy(buffer, str);
}

illustrates a vulnerability where buffer can overflow. The function uses strcpy, which does not check the length of the input string. If str exceeds 16 characters, it will overwrite adjacent memory, potentially influencing return addresses and thereby may grant control over the program flow, leading to application crashes or unauthorized behavior.

Page 14

• What Happens on Buffer Overflow?

  • When str exceeds 16 characters, vulnerability can lead to control over program flow or application crash.

Page 15

• Buffer Overflow Concepts

  • Classification: Writing exceeds buffer size, leading to crashes or overriding return addresses.

Page 16

• Basic Exploit Mechanism

  • Return address point to a location on the stack which contains executable code, with buffer containing junk and injected code. When function return, jump to the injected code. Overflow buffer will have new return address, junk and injected code where injected code will start a shell. execute(‘/bin/sh’)

Page 17

• Injected Code Execution

  • When returning from function, control jumps to shell initial code (execute('/bin/sh')).

Page 18

• Crafting Buffer Overflow

  • Change the return address through memory manipulation, specifying the position of injected code.

  • Knowledge of addresses and offsets is essential.

Page 19

• Example of Injected Shell Code

  • Code represented in hex for executing shell operations with int $0x80</code> and specific registers manipulation as detailed.</p></li></ul></li></ul><h3 id="712194e5-2689-4070-b56c-591d8bde11a3" data-toc-id="712194e5-2689-4070-b56c-591d8bde11a3" collapsed="false" seolevelmigrated="true">Page 20</h3><ul><li><p><strong>Retrieving Object Code</strong></p><ul><li><p>Use of <code>objdump</code> for disassembly and verification of injected shell code structure.</p></li></ul></li></ul><h3 id="f2feeecb-4c91-4917-83c4-3594bc8128a3" data-toc-id="f2feeecb-4c91-4917-83c4-3594bc8128a3" collapsed="false" seolevelmigrated="true">Page 21</h3><ul><li><p><strong>Crafting Exploit Methodology</strong></p><ul><li><p>Strategies involving setting the right return address and positioning of shellcode effectively in the buffer.</p></li></ul></li></ul><h3 id="02a30cb5-8d47-4780-8f94-9f16cf73aa53" data-toc-id="02a30cb5-8d47-4780-8f94-9f16cf73aa53" collapsed="false" seolevelmigrated="true">Page 22</h3><ul><li><p><strong>Other Attack Vectors</strong></p><ul><li><p>Include return-oriented programming, heap overflow, string overflow, integer overflow.</p></li></ul></li></ul><h3 id="16532ddb-d4e0-42a7-bfa4-f8f835cccc94" data-toc-id="16532ddb-d4e0-42a7-bfa4-f8f835cccc94" collapsed="false" seolevelmigrated="true">Page 23</h3><ul><li><p><strong>Return Oriented Programming (ROP)</strong></p><ul><li><p>Techniques involving stack buffer overflows without the need to inject code directly, using already loaded code to execute actions.</p></li><li><p><strong>Stack buffer overflow</strong></p><ul><li><p>Change return address</p></li><li><p>Inject code to stack</p></li><li><p>Execute stack</p></li><li><p>Does not work when stack is not executable</p></li></ul></li></ul></li><li><p>Traditional Stack Buffer Overflow vs. ROP</p><p class="whitespace-pre-wrap break-words">Traditional stack buffer overflows worked by:</p><ol><li><p>Overflowing a buffer on the stack</p></li><li><p>Injecting malicious code into the stack</p></li><li><p>Overwriting the return address to point to this injected code</p></li><li><p>When the function returns, the malicious code executes</p></li></ol><p class="whitespace-pre-wrap break-words">This approach was mitigated by <strong>non-executable stack</strong> protections (NX/DEP), which prevent code on the stack from executing.</p><h3 id="2b154989-8373-48dc-9094-4854f77b3b0b" data-toc-id="2b154989-8373-48dc-9094-4854f77b3b0b" collapsed="false" seolevelmigrated="true">ROP Technique</h3><p class="whitespace-pre-wrap break-words">Since code injection no longer works with these protections, ROP takes a different approach:</p><ol><li><p>Instead of injecting new code, ROP reuses existing code already loaded in memory</p></li><li><p>It identifies small code sequences in existing libraries that end with a return instruction (called "gadgets")</p></li><li><p>It chains these gadgets together by carefully constructing a fake stack</p></li><li><p>Each gadget performs a small operation and then "returns" to the next gadget in the sequence, enabling the attacker to execute arbitrary code while bypassing the security mechanisms designed to prevent such attacks. </p></li></ol></li></ul><h3 id="4dbb74b8-4161-40a8-88c3-ea0579d86a6f" data-toc-id="4dbb74b8-4161-40a8-88c3-ea0579d86a6f" collapsed="false" seolevelmigrated="true">Page 24</h3><ul><li><p><strong>Finding Code to Exploit</strong></p><ul><li><p>Using functions or code snippets already present in the memory to direct control to desired execution paths through manipulations.</p></li></ul></li></ul><h3 id="deb86f4a-5460-4969-b8fd-786be9f83bb9" data-toc-id="deb86f4a-5460-4969-b8fd-786be9f83bb9" collapsed="false" seolevelmigrated="true">Page 25</h3><ul><li><p><strong>Executing Shell from libc</strong></p><img src="https://knowt-user-attachments.s3.amazonaws.com/c1c3aaeb-34c9-4923-b208-e895b573e94a.png" data-width="100$esp: Points to the top of the stack, marking the most recent point in use.

  • $ebp</code>: Represents the base pointer, delineating the current stack frame.</p></li><li><p><code>$eip: Contains the current instruction address indicating which code is being executed next.

Buffer Overflow Example

• Function declaration:

void vul(char *str) { 
    char buffer[16]; 
    strcpy(buffer, str); 
}

• The implementation of the vulnerable buffer demonstrated here is susceptible to overflowing; if the input str exceeds 16 characters, it compromises adjacent memory, leading to potential control over program flow or even crashing the application, showcasing the dire consequences of insufficient validation.

Crafting Buffer Overflow

Memory Manipulation

• Techniques for changing the return address through crafted inputs emphasize the necessity of understanding memory layout and address offset calculations.

• Knowledge regarding immediate addresses and their offsets is critical when developing effective exploits for buffer overflows, as the correct manipulation of these leads to successful control over program execution flow.

What are the attacks?

1. Return oriented programming

2. Heap Overflow

3. String overflow

4. Integer overflow