% Secure Programming Lab 1: Data Corruption
% School of Informatics, University of Edinburgh
% 3pm-6pm, 2nd February 2016

# Exercise 1

## Part 1: classic stack overflow

**Checkpoint 1.** How can you tell the program will run as setuid root,
and how can you make a compiled program run as setuid root?

**Checkpoint 2.** Briefly explain the output of these tools, and
how the compiler flags influence the output of `checksec.sh` (look
at the `Makefile` to see how `gcc` was invoked).

**Checkpoint 3.** Explain what your shellcode does and how you
  made it.
  
**Checkpoint 4.** Explain how your exploit works.

**Checkpoint 5.** Provide your patch to fix the notice board program
(use `diff -c <oldprogram> <newprogram>`).

## Part 2: another vulnerability

**Checkpoint 1.** Identify the security flaw in the new version of
  `noticeboard.c`; explain what it allows and demonstrate an exploit
  that compromises the standard system security.

**Checkpoint 2 (optional).** Briefly, explain how your root shell
 exploit works.

**Checkpoint 3.** Give a patch which fixes the second version of
  `noticeboard.c`.

# Exercise 2

**Checkpoint 1.** Explain the format of the messages sent by the client.

**Checkpoint 2.** Provide a program (or shell script) which crashes
  the server remotely.

**Checkpoint 3.** Give a patch to fix the problem(s).

# Exercise 3

**Checkpoint 1.**  How do you get the address of a `/bin/sh` string, and if you can't find one in memory how to inject one?

**Checkpoint 2.**  Where does the `system` function exist in libc?  Where is it loaded in your program?

**Checkpoint 3.**  How do you call `system` as you return from the overflown function with your string as its argument?

**Checkpoint 4.**  A program which crashes may leave a log file somewhere.  You should also ensure your program exits cleanly.  How do you do this?

Exercise 4 (Optional)
=====================

**Checkpoint 1.** Identify the security flaw in the code, and provide
  the relevant CVE number.

**Checkpoint 2.** Briefly summarise the problem and explain and why
  it is a security flaw.

**Checkpoint 3.** Give a recommendation for a way to repair the problem.

**Checkpoint 4 (very optional).** Build a *proof-of-concept* to
  demonstrate the security flaw and explain how it might be exploited;
  check that your repair (or the current released version) prevents
  your attack.