HW 2 for CSCE 489/689 - Software Security
Due:  15 October 2018 by 8:00am

********************************************************************************
* Work individually on the assignment.                                         *
*                                                                              *
* Don't lie, cheat, or steal.                                                  *
*                                                                              *
* Attack the software, not the infrastructure.                                 *
********************************************************************************

The goal of this assignment is to break the Secure Log software we built in Homework 1.
* This is practice for the Break-it phase of the project =)

You have the source code for a pseudo-randomly chosen implementation.
* target.tgz
  |- build/
  |  |- logappend.cpp - implements logappend
  |  |- logread.cpp   - implements logread
  |  |- common.h      - contains code common to both logappend and logread
  |  |- Makefile      - builds the logappend and logread executables

You also have an updated test runner that allows any shell command to be run.  This means you can write test cases that use commands like mkdir, cp, mv, rm, echo, python, etc.  Which means you can do serious damage to the environment.  This is why you _really_ want to use a VM.
* run_test.py - usage: run_test.py [-h] [-p PREFIX] -t TEST [-k] [-v] [--allow-shell]
* sec1.json   - example test using a shell command

How to use a VM for penetration testing 101:
* This is a basic skill that will save your proverbial life
* Snapshots. (c.f. https://www.youtube.com/watch?v=XNtTEibFvlQ&feature=youtu.be&t=77)
* BEFORE starting your penetration test
	- Get all your tools installed
	- Get your environment set up just the way you like it
	- Put the target code on the VM
	- Take a snapshot of the VM in this stable and ready state
* Go wild
	- Keep a record of your wild: notes of what your try, what works, what doesn't, what deserves further investigation, etc.
	- Hit it with everything you've got
	- If you get (un)lucky, something you hit it with will cause the system to become unstable
		+ your notes will help you know what you did
	- Shut it down
	- Restore to the previous stable snapshot
* Take a new snapshot periodically so you don't lose too much if/when the system becomes unstable or you delete something you need

You still have access to the Oracle on ritchey.tk
* You must be on the connect.tamu.edu VPN or on campus to access the site
* The online Oracle IS NOT configured to allow arbitrary commands (hence using your own VM)
	- logappend and logread are the ONLY commands allowed
* If you think the Oracle is incorrect, unavailable, lacking integrity or confidentiality, let me know ASAP
	- email me <pcr@tamu.edu> (responsible disclosure)
	- there is extra credit it in for you to help me figure out what went wrong and how to fix it

You are looking for 3 kinds of defects in the target:
1) Correctness
2) Availability
3) Integrity or Confidentiality

Correctness: 1 point
--------------------
A test case demonstrates a correctness defect iff the result for the same test case against the Oracle is different than the result from the target and neither times out or gives "integrity violation".
	Example: Target returns 0, but Oracle returns 255.

Availability: 2 points
----------------------
A test case demonstrates an availability defect iff the test case causes the target to crash.  A crash is an unexpected termination.
	Example: Target terminates with a Segmentation Fault (receives SIGSEGV).

Integrity or Confidentiality: 4 points
--------------------------------------
A test case demonstrates an integrity or confidentiality defect iff the result for the same test case against the Oracle is "integrity violation" and the target does not crash but gives some output which is neither "invalid" nor "integrity violation".
	Example: Target allows a read that the Oracle does not.

Attacking the Infrastructure: negative all the points
-----------------------------------------------------
DO NOT ATTACK THE INFRASTRUCTURE.  Any test case designed to attack the infrastructure is out of bounds and will negate points earned from valid exploits.  For example, rm -rf /* is out of bounds.  Your goal is to exploit the Secure Log software to violate correctness, availability, integrity, and confidentiality of the logging system.  Making the Secure Log software crash is good.  Making the whole system crash is bad (unless done by logappend or logread due to malicious input).


Submission
----------
* Make a directory called "breaks" and keep your exploits there.
* Exploits are:
	- a test case in JSON format (same as for HW 1 and the Bug Hunting activity).
		+ with one additional field: "break": "correctness" | "crash" | "security"
		  e.g. {"tests":[<expectedIO>],"break":"correctness"}
		+ named break.json
	- and a brief description of the defect, including file name, line number, and how it should be fixed
		+ named description.txt
	- in a folder, e.g.
		+ buffer_overrun/
		  |- description.txt - tells what, where, and how to fix the defect
		  |- break.json      - test case exploiting the defect
* tar and compress your breaks directory
	- tar -czf breaks.tar.gz breaks/
* Submit breaks.tar.gz to eCampus


Scoring
-------
* 0 defects earns the grade 0
* The average total score of defects earns the grade 80
* The maximum total score of defects earns the grade 100
* Any 3 points define a polynomial of degree 2
	- (0,0)
	- (AVG,80)
	- (MAX,100)
	- grade(score) = max(0, min(100, A*score^2 + B*score))
		where B = (80*MAX/AVG - 100*AVG/MAX) / (MAX - AVG)
		  and A = 80/AVG^2 - B/AVG