% Secure Programming Lab 1: Data Corruption
% School of Informatics, University of Edinburgh
% 3pm-6pm, 7th February 2017

Exercise 0
==========

## Part 1: Effective user id

**Checkpoint 1.** Briefly explain what is an effective user id and why
the two binary compiled from the same source code will print a different
effective user id when they are executed.

**Checkpoint 2.** Spot the difference of the two binary files, which part shows
that their effective user ids are different?

**Checkpoint 3.** Briefly explain the usage of chown and chmod
  operation in the `Makefile`.

**Checkpoint 4.** What is a suid/sguid permission bit and what are the
differences of running the same binary with or without these bits set?

**Checkpoint 5.** What is the security concern if a vulnerable program
is running with a seuid bit?

**Checkpoint 6.** Use the seuid bit technique to allow the `open` binary 
to read the file `secret`. State the command you have used.

## Part 2: Simple buffer overflow

**Checkpoint 1.** How many user inputted characters are allowed to store
in the array `password` without overflowing it?

**Checkpoint 2.** If the length of the user input exceed the size of `password`,
where will strcpy() store the remaining characters?

**Checkpoint 3.** State the user input you have used and briefly describe why it is working.


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 (Advanced)
=====================

**Checkpoint 1.** How do you get the address of a `/bin/sh` string,
  and if you can't find one in memory how would you 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
  can 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.