Csep-564-Lec-2

Memory Safety

Mostly, attacks are concerned with virtual addresses relevant to a particular program.
Whereas physical addresses really only come into play in side channel attacks.
We're assuming all code in this class is written in C (or any unsafe language).
But fundamentally we're really only interested in the executable binary.
bug: software doesn't work right
vulnerability: a malfunction that can be used for an adversary's goals
exploit: a mechanical set of operations that make use of a vulnerability
- an exploit can also be considered a program for a weird machine

Mostly this is a recap of stuff I've just learned in ostep, but some helpful tidbits:
esp: stack ptr
ebp: frame ptr
eax: register where return values go
This class assumes x86_32 so everything is 4 bytes.
When a function f(int a, int b) is called:
- Push b
- Push a
- Push ret
- Push ebp
- Push local vars

| locals | saved ebp | ret | arg a | arg b |
         ^
        esp

A classic buffer overflow vulnerability is shown below, with no check on the str length.

void func(char *str) {
    char buf[126];
    strcpy(buf, str);
}

We'll overflow the ret address on the stack to point back to the str buffer, and put malicious assembly instructions there.
So, for homework, we need to use a debugger to find the correct address for this attack code to put into ret.

A bunch of C functions are safe. New versions have evolved, e.g.

strncpy(char *dest, const char *src, size_t n)

will only copy up to n bytes. But, you've gotta use the right value for n!

We'll have to write an exploit which only allows overflowing a buffer by one byte.

Hint: It's little endian x86_32 bit system. We can overwrite the first byte of the saved frame pointer, which is the least significant bit of the frame pointer. So, we can shift the frame pointer (slightly) into the buffer.
Use gdb to find the correct addresses.

Another variant of the overflow is to overwrite a C function pointer, rather than the RET address.

There are two syntaxes. E.g. a = b: