CS 111 - Scribe Notes

Final Lecture — June 4^th, 2008

By Charles Ju and Matthew Snider

Security: Threats

Modeling and Classification

1. insiders
2. social engineering
3. network attacks
   • virus/DBD (drive by downloads, 10% of websites, 2007 estimate)
   • DoS Attacks (Denial of Service)
   • Buffer overruns
4. device attacks
   • virus on CD-R or USB
   • dongles on keyboard

General Functions Needed in Security Mechanisms

• Authentication — proving who you are
• Authorication — proving you have rights
• Auditing — recording what you've done
• Integrity — prevent/detect modifications
• Correctness
• Efficiency — a slow system ⇒ DoS

Authentication

prevents masquerading
external authentication (for initial access)

• passwords/biometrics (fingerprints/retinal scans)/identity tokens
• possible attacks: fake fingers/password snooping/steal tokens/insiders

internal authentication (for later access within the system, for efficiency)

• inside process descriptor (uid+gid+...)
• possible attacks: bugs in kernel

External Authentication is based on: who the principal is (e.g. brain scan)
something the principal has (ID token)
something the principal knows (passwords)

Authentication Building Blocks

• Cryptographic Hash Functions ("one way" hash)
  • resists the "append junk" attack
  • e.g. SHA1(message) ⇒ 160-bit hash value
  • SHA1(M) = H : Given only H, it is infeasible to compute M, or any other M' for some SHA1(M') = H
• Symmetric Encryption ("secret key")

  Given	Getting
  M,K	{M}K is easy
  {M}K, K	M is easy
  {M}K	M is hard
  M, {M}K	K is hard

• Asymmetric Encryption ("public key")
  U = public key, K = private key

  Given	Getting
  M,U	{M}U is easy
  {M}U, K	M is easy
  {M}U, U	M is hard
  U	K is hard

  • RSA is the most common
  • Public Key encryption is more expensive

Assume shared secret key, K

A ⇒ B	{I'm Alice}K
B ⇒ OK	(vulnerable to a capture and replay attack)

Solved using a nonce (noise ora randomly generated key)

A ⇒ B	I'm Alice
B ⇒ A	Nonce
A ⇒ B	{Nonce}K
B ⇒ A	OK

Using Public Keys

A ⇒ B	{NonceA∩Hi, I'm Alice}UB
B ⇒ A	{NonceA∩NonceB}UA
A ⇒ B	{NonceB∩Ksession}UB
	Ksession is a symmetric key just for this conversation

Authenticating a packet in a bulk transfer

HMAC algoritm (assumes shared key K):
SHA1( (k^∩pad₁)^∩SHA1( (K^∩pad₂ )^∩M) ) ⇒ 160 bits
Gives you:

1. Authentication
2. Integrity

Weakness of SHA1 Prevented by HMAC padding

Given	Getting
M	SHA1( M ∩ glitch )

Authorization

Who has what permission?

Traditional Linux:		user	group(s)		user rwx	group rwx	other rwx
		per process			per file

ACLs (Access Control Lists)

	for each principal (e.g. user)
		for each object (e.g. file)
			for each type of access (e.g. read, write, rename)
				allowed or not allowed
	

Problems with ACLs:

• A Pain to maintain
• What are the default bits for a new object? a new principal? a new operation?

in UNIX defaults are decied by:

• 3^rd arg to open(...) or mkdir(...)
• + umask
• + uid of the process (to determine the file owner)
• + gid of the process (to determine the file group)
• + ...

ACLs originated on Windows NT (now on Solaris, some Linux*)
Solaris: log into Seasnet

		$ getfacl .
		user::rwx
		group::r-x
		other::r-x
		myta::rwx
		$ setfacl -r -m group:tas:rwx .
	

Role Based Access Control

Users (principals) can assume roles
e.g. assume role as operator to do backups
or assume role as instructor to issue grades

• rights are asociated with roles, not with principals
• if you assume another role, you get its rights
• you can have multilpe sessions with different roles

Process A	Process B
secure info written by attacker User A A's Files are visible only to A A is in a chrooted Jail No Internet Access No Shared Memory	web server (visible to public) written by attacker User B B's Files are visible only to A B is in a chrooted Jail Neither side can see sockets Neither side can see ps

Covert Channel

Commication via the clock and monitoring system resources
Very difficult to defend against

Ken Thompson - one of the 2 designers of UNIX

Lecture title "Reflections on Trusting Trust"
http://cm.bell-labs.com/who/ken/trust.html

The exploit occurs when gcc source code is modified to contain code that inserts both a backdoor into gcc and a backdoor into login.c of the UNIX or Linux source code. The compiled code will contain the exploit despite the source code not containing any backdoor. Any subsequent detection methods can be thwarted by the gcc hack. The only way to prevent this is to compare compiled code with a Trusted Computing Base.