ISF LAB - BUFFER

Name: B Sai Sidharth

USN: 1BM21IS043

Understanding of Buffer Overflow:

● Buffer Overflow is a situation which occurs when more data is tried to be written in
a fixed buffer.
● This can lead to the overwriting of adjacent memory, causing unexpected behavior,
crashes, or even security vulnerabilities.

Types of Common Weakness Enumeration (CWE) with example

program and output:

1. CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer

Overflow'):
A buffer overflow happens when a program writes more data to a buffer than it can
hold, which may overwrite adjacent memory, causing unpredictable behavior or
allowing attackers to exploit the overflow.

Code:

Output:
2. CWE-119: Improper Restriction of Operations within the Bounds of a Memory
Buffer:
This weakness occurs when there is insufficient checking of memory bounds
during read or write operations, potentially leading to buffer overflows or
underflows.

Code:

Output:
3. CWE-121: Stack-based Buffer Overflow:
It refers to a type of vulnerability where a buffer (a region of memory) located on
the stack is overflowed, meaning data is written past the buffer's allocated size.
This overflow can overwrite adjacent memory locations, such as local variables,
control data (like the function return address), or other important structures in the
call stack. Stack-based buffer overflows are one of the most common and
dangerous types of buffer overflows because they allow attackers to overwrite the
return address of a function and execute arbitrary code, typically in the form of
shellcode.

Code:

Output:
4. CWE-122: Heap-based Buffer Overflow:
CWE-122 refers to Heap-based Buffer Overflow, which occurs when a buffer
located in the heap memory region is overflowed, causing unintended behavior or
corruption of adjacent memory. The heap is typically used for dynamic memory
allocation, and buffer overflows in this area can be particularly dangerous because
they can affect pointers, function pointers, or other critical data structures, leading
to potential arbitrary code execution, data corruption, or program crashes.

Code:

Output:
5. CWE-125: Out-of-bounds Read:
CWE-125: Out-of-bounds Read refers to a type of vulnerability where a program
reads data from memory outside the bounds of a buffer or array. This can lead to
unpredictable behavior, including crashes, incorrect data being returned, or
exposure of sensitive data.

Unlike buffer overflows, which are typically associated with writing data past the
allocated size of a buffer, out-of-bounds reads occur when a program attempts
to read beyond the allocated memory for a buffer or array. The resulting data read
can be invalid, uninitialized, or from unrelated regions of memory, which can cause
security vulnerabilities or program instability.

Code:

Output:
6. CWE-131: Incorrect Calculation of Buffer Size:
CWE-131: Incorrect Calculation of Buffer Size refers to a vulnerability where a
program miscalculates or incorrectly determines the required size for a buffer,
leading to various types of memory-related issues. This typically occurs when the
program allocates or accesses memory based on incorrect assumptions, such as
using an incorrect data type or failing to account for null terminators in strings.

If the buffer size is calculated incorrectly, it can result in a buffer overflow (if the
buffer is too small), or memory may be wasted or underutilized (if the buffer is too
large), potentially causing memory corruption, program crashes, or data
corruption.

Code:

Output:
Prevention Methods:

1. Bounds Checking
○ Always check that data being written to a buffer fits within its allocated size.
This can be done manually by ensuring that user input or data manipulation
does not exceed the buffer's limit.
○ Example: Before copying data into a buffer, ensure the source size is less
than or equal to the buffer size.
2. Use Safer Functions
○ Avoid using unsafe C functions like strcpy(), sprintf(), gets(), and
scanf() which do not perform bounds checking.
○ Safer alternatives include:
■ strncpy() instead of strcpy()
■ snprintf() instead of sprintf()
■ fgets() instead of gets()
■ scanf_s() instead of scanf()
3. Stack Canaries (Stack Smashing Protection)
○ Stack canaries are special values placed on the stack before the return
address. If a buffer overflow occurs, the canary value will be altered, and
this can be detected before the program continues execution.
○ Modern compilers (like GCC) often enable stack protection by default with
the -fstack-protector flag, which adds a canary check during function
returns.
4. Non-Executable Stack (NX or DEP)
○ Non-executable (NX) or Data Execution Prevention (DEP) makes regions
of memory, such as the stack or heap, non-executable. This prevents
attackers from executing injected malicious code via buffer overflows.
○ Many modern operating systems and CPUs support this feature to prevent
execution of code from data sections.
5. Address Space Layout Randomization (ASLR)
○ ASLR randomizes the memory layout of a process, making it difficult for an
attacker to predict the location of key memory regions (like the stack, heap,
or shared libraries).
○ Even if an attacker exploits a buffer overflow, the location of critical data
structures (such as the return address) will be randomized, preventing easy
exploitation.
6. Control Flow Integrity (CFI)
○ CFI is a security technique that ensures a program's control flow only
follows legitimate paths. Buffer overflows often change control flow (e.g., by
 modifying return addresses), so by enforcing strict control flow policies,
exploits can be detected or mitigated.
○ This can be implemented via compiler flags or runtime protections.
7. Safe Memory Management Practices
○ Use memory management libraries or languages that prevent buffer
overflows, such as C++ STL containers (e.g., std::vector,
std::string), which handle size and memory allocation internally, or
safe languages like Python, Java, and Rust, which inherently prevent
buffer overflows by managing memory for you.
8. Stack Protector Flags and Compiler Hardening
○ Modern compilers, such as GCC and Clang, have various built-in defenses
against buffer overflows:
■ Stack protection (-fstack-protector or -fstack-
protector-all) to detect stack smashing.
■ Control Flow Integrity (CFI) via options like -fsanitize=cf.
■ Fortify Source (-D_FORTIFY_SOURCE=2) for safer handling of
certain library functions.
9. Use of Modern Languages with Memory Safety
○ Many modern languages like Rust or Go enforce memory safety at the
language level. These languages make buffer overflows nearly impossible
due to their automatic bounds checking and the absence of direct memory
manipulation capabilities (like malloc, free in C).
10. Heap Canaries and Guard Pages
○ Similar to stack canaries, heap canaries can detect heap-based buffer
overflows by placing special values near the heap memory and checking
them before accessing or freeing memory.
○ Guard pages are regions of memory between critical memory areas that are
not allocated, which help detect buffer overflows when writing past allocated
buffers.
11. Runtime Protection Mechanisms
○ SafeStack: An advanced protection mechanism that separates the "safe"
stack (for return addresses and function pointers) from the "unsafe" stack
(for regular local variables).
○ Memory-safe languages and tools: Tools like AddressSanitizer and
Valgrind can be used during development to detect memory corruption,
including buffer overflows.
12. Use of Canaries and Safe Functions in Security Libraries
○ Many security-focused libraries, like LibSafe, are designed to provide
secure versions of unsafe functions. Using these libraries helps minimize
the risks associated with buffer overflows.