# CSE4303 Introduction to Computer Security (Lecture 17)

> Due to lack of my attention, this lecture note is generated by AI to create continuations of the previous lecture note. I kept this warning because the note was created by AI.

#### Software security

### Administrative notes

#### Project details

- Project plan
  - Thursday, `4/9` at the end of class
  - `5%`
- Written document and presentation recording
  - Thursday, `4/30` at `11:30 AM`
  - `15%`
- View peer presentations and provide feedback
  - Wednesday, `5/6` at `11:59 PM`
  - `5%`

#### Upcoming schedule

- This week (`3/20`)
  - software security lecture
  - studio
  - some time for studio on Tuesday
- Next week (`4/6`)
  - fuzzing
  - some time to discuss project ideas
- `4/13`
  - Web security
- `4/20`
  - Privacy and ethics overview
  - time to work on projects
  - course wrap-up

### Overview

#### Outline

- Context
- Prominent software vulnerabilities and exploits
- Buffer overflows
  - Background: C code, compilation, memory layout, execution
  - Baseline exploit
  - Challenges
  - Defenses, countermeasures, counter-countermeasures

Sources:
- SEED lab book
- Gilbert/Tamassia book
- Slides from Bryant/O'Hallaron (CMU), Dan Boneh (Stanford), Michael Hicks (UMD)

### Context

#### Context: computing stack (informal)

| Layer | Example |
| --- | --- |
| Application | web server, standalone app |
| Compiler / assembler | `gcc`, `clang` |
| OS: syscalls | `execve()`, `setuid()`, `write()`, `open()`, `fork()` |
| OS: processes, mem layout | Linux virtual memory layout |
| Architecture (ISA, execution) | x86, x86_64, ARM |
| Hardware | Intel Sky Lake processor |

- User control is strongest near the application / compiler level.
- System control becomes more important as we move down toward OS, architecture, and hardware.

### Prominent software vulnerabilities and exploits

#### Software security: categories

- Race conditions
- Privilege escalation
- Path traversal
- Environment variable modification
- Language-specific vulnerabilities
  - Format string attack
  - Buffer overflows

#### Buffer Overflows (BoFs)

- A buffer overflow is a bug that affects low-level code, typically in C and C++, with significant security implications.
- Normally, a program with this bug will simply crash.
- But an attacker can alter the situations that cause the program to do much worse.
  - Steal private information
    - e.g. Heartbleed
  - Corrupt valuable information
  - Run code of the attacker's choice

#### Application behavior

- Slide contains a figure only.
- Intended point: normal application behavior can become attacker-controlled if input handling is unsafe.

#### BoFs: why do we care?

- Reference from slide: [IEEE Spectrum top programming languages 2025](https://spectrum.ieee.org/top-programming-languages-2025)

#### Critical systems in C/C++

- Most OS kernels and utilities
  - `fingerd`
  - X windows server
  - shell
- Many high-performance servers
  - Microsoft IIS
  - Apache `httpd`
  - `nginx`
  - Microsoft SQL Server
  - MySQL
  - `redis`
  - `memcached`
- Many embedded systems
  - Mars rover
  - industrial control systems
  - automobiles

A successful attack on these systems can be particularly dangerous.

#### Morris Worm

- Slide contains a figure / historical reference only.
- It is included as an example of how memory-corruption vulnerabilities mattered in practice.

#### Why do we still care?

- The slide references the NVD search page: [NVD vulnerability search](https://nvd.nist.gov/vuln/search)
- Why the drop?
  - Memory-safe languages
    - Rust
    - Go
  - Stronger defenses
  - Fuzzing
    - find bugs before release
  - Change in development practices
    - code review
    - static analysis tools
    - related engineering improvements

#### MITRE Top 25 2025

- Reference from slide: [MITRE CWE Top 25](http://cwe.mitre.org/top25/)

### Buffer overflows

#### Outline

- System Basics
  - Application memory layout
  - How does function call work under the hood
    - `32-bit x86` only
    - `64-bit x86_64` similar, but with important differences
- Buffer overflow
  - Overwriting the return address pointer
  - Point it to shell code injected

#### Buffer Overflows (BoFs)

- 2-minute version first, then all background / full version

#### Process memory layout: virtual address space

- Slide reference: [virtual address space reference](https://hungys.xyz/unix-prog-process-environment/)

#### Process memory layout: function calls

- Slide reference: [Tenouk function call figure 1](http://www.tenouk.com/Bufferoverflowc/Bufferoverflow2.html)
- Slide reference: [Tenouk function call figure 2](http://www.tenouk.com/Bufferoverflowc/Bufferoverflow4.html)

#### Process memory layout: compromised frame

- Slide reference: [Tenouk compromised frame figure](http://www.tenouk.com/Bufferoverflowc/Bufferoverflow4.html)

#### Computer System

High-level examples used in the slide:

```c
car *c = malloc(sizeof(car));
c->miles = 100;
c->gals = 17;
float mpg = get_mpg(c);
free(c);
```

```java
Car c = new Car();
c.setMiles(100);
c.setGals(17);
float mpg = c.getMPG();
```

Assembly-language example used in the slide:

```asm
get_mpg:
    pushq   %rbp
    movq    %rsp, %rbp
    ...
    popq    %rbp
    ret
```

- The same computation can be viewed at multiple levels:
  - C / Java source
  - assembly language
  - machine code
  - operating system context

#### Little Theme 1: Representation

- All digital systems represent everything as `0`s and `1`s.
  - The `0` and `1` are really two different voltage ranges in wires.
  - Or magnetic positions on a disk, hole depths on a DVD, or even DNA.
- "Everything" includes:
  - numbers
    - integers and floating point
  - characters
    - building blocks of strings
  - instructions
    - directives to the CPU that make up a program
  - pointers
    - addresses of data objects stored in memory
- These encodings are stored throughout the computer system.
  - registers
  - caches
  - memories
  - disks
- They all need addresses.
  - find an item
  - find a place for a new item
  - reclaim memory when data is no longer needed

#### Little Theme 2: Translation

- There is a big gap between how we think about programs / data and the `0`s and `1`s of computers.
- We need languages to describe what we mean.
- These languages must be translated one level at a time.
- Example point from the slide:
  - we know Java as a programming language
  - but we must work down to the `0`s and `1`s of computers
  - we try not to lose anything in translation
  - we encounter Java bytecode, C, assembly, and machine code

#### Little Theme 3: Control Flow

- How do computers orchestrate everything they are doing?
- Within one program:
  - How are `if/else`, loops, and switches implemented?
  - How do we track nested procedure calls?
  - How do we know what to do upon `return`?
- At the operating-system level:
  - library loading
  - sharing system resources
    - memory
    - I/O
    - disks

#### HW/SW Interface: Code / Compile / Run Times

- Code time
  - user program in C
  - `.c` file
- Compile time
  - C compiler
  - assembler
- Run time
  - executable `.exe` file
  - hardware executes it
- Note from slide:
  - the compiler and assembler are themselves just programs developed using this same process

#### Assembly Programmer's View

- Programmer-visible CPU / memory state
  - Program counter
    - address of next instruction
    - called `RIP` in x86-64
  - Named registers
    - heavily used program data
    - together called the register file
  - Condition codes
    - store status information about most recent arithmetic operation
    - used for conditional branching
- Memory
  - byte-addressable array
  - contains code and user data
  - includes the stack for supporting procedures

#### Turning C into Object Code

- Code in files `p1.c` and `p2.c`
- Compile with:

```bash
gcc -Og p1.c p2.c -o p
```

- Notes from the slide
  - `-Og` uses basic optimizations
  - resulting machine code goes into file `p`
- Translation chain
  - C program -> assembly program -> object program -> executable program
- Associated tools
  - compiler
  - assembler
  - linker
  - static libraries (`.a`)

#### Machine Instruction Example

- C code

```c
*dest = t;
```

- Meaning
  - store value `t` where designated by `dest`
- Assembly

```asm
movq %rsi, (%rdx)
```

- Interpretation
  - move 8-byte value to memory
  - operands
    - `t` is in register `%rsi`
    - `dest` is in register `%rdx`
    - `*dest` means memory `M[%rdx]`
- Object code

```text
0x400539: 48 89 32
```

- It is a 3-byte instruction stored at address `0x400539`.

#### IA32 Registers - 32 bits wide

- General-purpose register families shown in the slide
  - `%eax`, `%ax`, `%ah`, `%al`
  - `%ecx`, `%cx`, `%ch`, `%cl`
  - `%edx`, `%dx`, `%dh`, `%dl`
  - `%ebx`, `%bx`, `%bh`, `%bl`
  - `%esi`, `%si`
  - `%edi`, `%di`
  - `%esp`, `%sp`
  - `%ebp`, `%bp`
- Roles highlighted in the slide
  - accumulate
  - counter
  - data
  - base
  - source index
  - destination index
  - stack pointer
  - base pointer

#### Data Sizes

- Slide is primarily a figure summarizing common integer widths and sizes.

#### Assembly Data Types

- "Integer" data of `1`, `2`, `4`, or `8` bytes
  - data values
  - addresses / untyped pointers
- No aggregate types such as arrays or structures at the assembly level
  - just contiguous bytes in memory
- Two common syntaxes
  - `AT&T`
    - used in the course, slides, textbook, GNU tools
  - `Intel`
    - used in Intel documentation and Intel tools
- Need to know which syntax you are reading because operand order may be reversed.

#### Three Basic Kinds of Instructions

- Transfer data between memory and register
  - load
    - `%reg = Mem[address]`
  - store
    - `Mem[address] = %reg`
- Perform arithmetic on register or memory data
  - examples: addition, shifting, bitwise operations
- Control flow
  - unconditional jumps to / from procedures
  - conditional branches

#### Abstract Memory Layout

```text
High addresses
Stack              <- local variables, procedure context
Dynamic Data       <- heap, new / malloc
Static Data        <- globals / static variables
Literals           <- large constants such as strings
Instructions
Low addresses
```

#### The ELF File Format

- ELF = Executable and Linkable Format
- One of the most widely used binary object formats
- ELF is architecture-independent
- ELF file types
  - Relocatable
    - must be fixed by the linker before execution
  - Executable
    - ready for execution
  - Shared
    - shared libraries with linking information
  - Core
    - core dumps created when a program terminates with a fault
- Tools mentioned on slide
  - `readelf`
  - `file`
  - `objdump -D`

#### Process Memory Layout (32-bit x86 machine)

- This slide is primarily a diagram.
- Key idea: a `32-bit x86` process has a standard virtual memory layout with code, static data, heap, and stack arranged in distinct regions.

We continue with the concrete runtime layout and the actual overflow mechanics in Lecture 18.