CS155: Homework #1
Spring 2017
Due: Thursday, Apr. 27
Problem 1: Control hijacking
A proposal for preventing stack buffer overflow attacks is based on making a backup copy of the return address when a function starts. The backup copy is written to a shadow stack located at some random location L on the heap. In the function epilog, just before the function is about to return, the backup copy of the return address is compared to the return address on the stack and if they differ the program exits. Otherwise, the return instruction is executed normally.(a) Explain why this mechanism can make it harder to mount a stack buffer overflow attack.
(b) Give sample C code that is vulnerable to a stack buffer overflow attack even if this mechanism is used. For example, consider the case of function pointers stored on the stack.
Problem 2: Return oriented programming
Suppose an attacker finds the following code fragments in the libc library once it is loaded in memory:
0x40002000: pop eax // pop top of stack into register eax ret 0x40002700: pop ebx // pop top of stack into register ebx ret 0x40002948: move [ebx], eax // write the value of eax to location ebx ret
Moreover, the attacker discovers a stack buffer overflow in some vulnerable application where a string buffer can overflow. Explain how in an environment where the stack is marked non-execute the attacker can nevertheless cause the vulnerable application to write the value 0x30000000 to memory address 0x48000000 and then jump to address 0x40088888. Your answer need only show the contents of the stack in the table below right after the buffer overflow takes place.
Problem 3: Memory management
The iOS _MALLOC(size_t size, int type, int flags) function allocates size bytes on the heap. Internally blocks are represented as a length field followed by a data field:
struct _mhead {
size_t mlen;
char dat[0]; }
The mlen field is used by the free()
function to determine how much space needs to be freed.
In iOS 4.x the _MALLOC function was implemented as follows:
1 void * _MALLOC(size_t size, int type, int flags) {
2 struct _mhead *hdr;
3 size_t memsize = sizeof (*hdr) + size;
4 hdr = (void *)kalloc(memsize); // allocate memory
5 hdr->mlen = memsize;
6 return (hdr->dat);
7 }
In iOS 5.x the following two lines were added after line 3:
int o = memsize < size ? 1 : 0;
if (o) return (NULL);
Why were these lines added in iOS5.x? Briefly describe an attack
that may be possible without these lines.
Problem 4: Unix access control
In Unix, every process has a real user id (ruid), an effective user id (euid), and a saved user id (suid). Processes with an euid of 0 have special root privileges.- If a process with user id n forks to create another process, what user id does the new process have? (Hint: it's the same answer for euid, ruid, and suid.)
-
If a process with euid n makes a setuid system call, what possible
euids can the process run with after the call, in each of the following situations:
- Before: euid = n > 0, saved user id suid=m and real user id ruid = m. After:?
- Before: n=0 After:?
- In qmail, most modules run under separate user ids. Similarly, each Android application runs in a separate process using a separate user id. From a security standpoint, what is the advantage of assigning separate uids instead of using the same uid for all? Explain.
- The Android zygote process that creates new processes runs as root. After forking to create a new process, setuid is normally called. Explain what uid the new process has initially and why it is important to call setuid? What security purpose does this serve?
-
When a Unix user wishes to change her password, she uses the passwd program.
The Unix password file is usually public readable but (for obvious reasons)
can only be written by processes with root privileges.
- How should the setuid bit be set on this passwd program? Explain how this lets a user change her password.
- Why does this make it important to write the passwd program source code carefully?