Lecture 6 Notes;  April 11, 1997; Notetaker: Alan Jondle

I.  Announcements
	A.  Homework #1 now due on Wednesday, April 16.
	B.  Handout on Web this weekend.
	C.  Target System's IP address will be posted to the newsgroup.

II.  Target System
	A.  Solaris 2.5.1
	B.  No social engineering (or lock picking)
	C.  It is running network services
	D.  Not allowed to ask for help on internet, or through other means
	E.  Can read things from the internet.
		1.  Example - CERT advisories
	F.  Whatever you do, document it thoroughly.

III.  How do you look for potential flaws?
	A.  Rigourous theories
		1.  Specific systems
		2.  Specific flaws
	B.  Flaw Hypothesis Methodology
		1.  Information Gathering
			a.  System Manuals
			b.  Internet
			c.  Well known flaws - target system may have similar
			flaw
				1.  Example - machine with no hardware multiply
				or divide, emulated in kernel mode with
				pointers.  The quotient was checked to make
				sure it was in user space, but the remainder
				was not.  Similar flaw found in 32-bit multiply
				with the low order bits.
			d.  Design flaws
				1.  In environment
				2.  With specifications (do they match the
				policy)
					a.  Example - Unix designed to prevent
					accidental deletion of another's files,
					now it is used in industry.
				3.  Interface
					a.  Between Systems
						1.  Example - Unix connected to
						PC and trusting it.
					b.  Between parts of a system
						1.  Example - Unix program
						pruning the environment, but
						not removing more than one path
						statement if two or more path
						statements exist.
				4.  People
					a.  Example - Trojan Horse
					b.  Example - Picking bad password
			e.  Implementation
				1.  Implemention to design has no proof, only a
				"good" argument
					a.  Common to all systems
					b.  Typically make assumptions about
					the environment
					c.  Example - Sendmail is approx.
					60,000 lines of code, and has a
					configuration file designed for
					machines, not people.  So it is easy to
					make code mistakes, and easy to make
					configuration mistakes.
				2.  Inconsistencies
					a.  Example - NFS uid 32bits and Unix
					uid 16 bits
		2.  Flaw Hypothesis
			a.  Where do you think flaws exist?
			b.  Brainstorming
			c.  Group good idea - bounce ideas off one another
			d.  Write ideas on form
				1.  Problem:  What it is (Summary)
				2.  Priority (Arbitrary, will you achieve goal
				if it exists?)
				3.  Description (Detailed)
				4.  References
				5.  Attack Strategy (How would it be exploited)
				6.  Checking Stategy (How would you see if it
				exists)
				7.  Fixes
			e.  Check
			f.  If need to exploit
				1.  Not on a production system
				2.  Log
				3.  Append program
				4.  Make it repeatable
			g.  What failed, why, and how can it be detected?
			h.  It is always better to avoid breaking in.
			i.  Don't exceed authority, and don't damage anything
		3.  Flaw Generalization
			a.  Look for patterns
			b.  Example vi and path
		4.  Flaw Elimination
			a.  People who built system may have broader view.
			b.  Orange book - penetration test need to fix any
			flaws uncovered

IV.  Past Penetrations
	A.  Michigan MTS
		1.  Looked at design, internals
			a.  mode 1-4 supervisor, mode 6-8 user,
			supervisor drop into mode 5 sometimes
			b.  double indirect parameters - not updated atomically
			c.  read line routine
	B.  Burroughs
		1.  No assembler, only Algol
		2.  Compiler labeled code
		3.  Compiler trusted	Data -> Compiler -> Code
		4.  Backup to tape, modify tape, restore