CS502 Operating Systems Fall 2006

1
Protection and Security (Part 2)

• CS-502 Operating SystemsFall 2006
• (Slides include materials from Operating System
  Concepts, 7th ed., by Silbershatz, Galvin,
  Gagne and from Modern Operating Systems, 2nd ed.,
  by Tanenbaum)

2
Puzzle

• Alice wishes to send secret message to Bob
• She places message in impenetrable box
• Locks the box with unbreakable padlock
• Sends locked box to Bob
• Problem Bob has no key to unlock box
• No feasible way to securely send key to Bob
• How does Bob retrieve message?

3
Answer

• Bob adds 2nd unbreakable padlock to box
• Locks with own key
• Sends box back to Alice (with two padlocks!)
• Alice unlocks and removes her lock
• Sends box back to Bob
• Bob unlocks his lock
• Opens box and reads message
• What could go wrong?

4
Authentication

• How does the machine know who it is talking to?
• Who do I say that I am?
• How can I verify that?
• Something I know (that nobody else should know)
• Something I have (that nobody else should have)
• Something I am (that nobody else should be)

5
Threats against authentication

• I want to pretend to be you
• I can steal your password
• the sticky note on your monitor or the list in
  your desk drawer
• by monitoring your communications or looking over
  your shoulder
• I can guess your password
• particularly useful if I can also guess your user
  name
• I can get between you and the system you are
  talking to

6
Getting between you and system you are talking to
7
Login Spoof

• I create a login screen in my process
• On a public machine
• Looks exactly like real one
• You log into system
• My login process records your user ID and
  password
• Logs you in normally
• Result I have gotten between you and system
  without your knowledge
• Also, I have stolen your user ID and password

8
The Trouble with Passwords

• They are given away
• They are too easy to guess
• They are used too often
• There are too many of them
• They are used in too many places

9
Some ways around the problem

• Better passwords
• longer
• larger character set
• more random in nature/encrypted
• Used less often
• changed frequently, one system per password
• challenge/response use only once

10
The Challenge/Response Protocol
Mary
Art
Hello, Im Art
Decrypt This RP
R
Hello Art! How can I help you?
11
Threat Steal passwords from the system

• Dont keep them in an obvious place
• Encrypt them so that version system sees is not
  same as what user enters
• or version on the wire

12
Too many passwords to remember?

• Third-party authentication
• Get someone to vouch for you
• The basics This guy says you know him.. Yes,
  I trust him, so you should too..
• Kerberos Certificate-based authentication
  within a trust community

13
What is in a certificate?

• Who issued it
• When was it issued
• For what purpose was it issued
• For what time frame is it valid
• (possibly other application-specific data)
• A signature that proves it has not been forged

14
Systems and Networks Are Not Different

• Same basic rules about code behavior apply
• Same authentication rules apply
• The same security principles apply

• Same Coding Rules Apply To
• An application
• Code which manages incoming messages
• Code which imposes access controls on a network
• ...

15
The Principles

• Understand what you are trying to protect
• Understand the threat(s) you are trying to
  protect against
• Also, costs and risks
• Be prepared to establish trust by telling people
  how you do it
• Assume that the bad guys are at least as clever
  as you are!

16
Security must occur at four levels to be effective

• Physical
• The best security system is no better than the
  lock on your front door (or desk, or file
  cabinet, etc.)!
• Human
• Phishing, dumpster diving, social engineering
• Operating System
• Protection and authentication subsystems
• Network
• Similar to OS
• Security is as weak as the weakest link in chain

17
How do these attacks work?

• Messages that attack mail readers or browsers
• Denial of service attacks against a web server
• Password crackers
• Viruses, Trojan Horses, other malware

18
The concept of a Vulnerability

• Buffer overflow
• Protocol/bandwidth interactions
• Protocol elements which do no work
• execute this messages
• The special case of mobile agents
• Human user vulnerabilities
• eMail worms
• Phishing

19
Another Principle

• There is a never-ending war going on between the
  black hats and the rest of us.
• For every asset, there is at least one
  vulnerability
• For every protective measure we add, they will
  find another vulnerability

20
Yet Another Principle

• There is no such thing as a bullet-proof barrier
• Every level of the system and network deserves an
  independent threat evaluation and appropriate
  protection
• Only a multi-layered approach has a chance of
  success!

21
Actual Losses

• Approximately 70 are due to user error
• More than half of the remainder are caused by
  insiders
• Social Engineering accounts for more loss than
  technical attacks.

22
What is Social Engineering?

• Hello. This is Dr. Burnett of the cardiology
  department at the Conquest Hospital in Hastings.
  Your patient, Sam Simons, has just been admitted
  here unconscious. He has an unusual ventricular
  arrhythmia. Can you tell me if there is anything
  relevant in his record?

23
Social Engineering (2)
From 3dksobinsky_at_zoom-internet.net Sent Sunday,
December 3, 2006 810 AM To rmstronger_at_charter.ne
t Subject Re Approved Please read the attached
file.
24
Program Threats

• Trojan Horse
• Code segment that misuses its environment
• Exploits mechanisms for allowing programs written
  by users to be executed by other users
• Spyware, pop-up browser windows, covert channels
• Trap Door
• Specific user identifier or password that
  circumvents normal security procedures
• Could be included in a compiler
• Logic Bomb
• Program that initiates a security incident under
  certain circumstances
• Stack and Buffer Overflow
• Exploits a bug in a program (overflow either the
  stack or memory buffers)

25
C Program with Buffer-overflow Condition

• include ltstdio.hgt
• define BUFFER SIZE 256
• int main(int argc, char argv)
• char bufferBUFFER SIZE
• if (argc lt 2)
• return -1
• else
• strcpy(buffer,argv1)
• return 0

26
Layout of Typical Stack Frame
27
Modified Shell Code

• include ltstdio.hgt
• int main(int argc, char argv)
• execvp('\bin\sh', '\bin \sh', NULL)
• return 0

28
Hypothetical Stack Frame
Before attack
After attack
29
Effect

• If you can con a privileged program into reading
  a string into a buffer unprotected from overflow,
  then
• you have just gained the privileges of that
  program in a shell!

30
Program Threats Viruses

• Code fragment embedded in legitimate programs
• Very specific to CPU architecture, operating
  system, applications
• Usually borne via email or as a macro
• E.g., Visual Basic Macro to reformat hard drive
• Sub AutoOpen()
• Dim oFS
• Set oFS CreateObject(Scripting.FileSystemObje
  ct)
• vs Shell(ccommand.com /k format
  c,vbHide)
• End Sub

31
Program Threats (Cont.)

• Virus dropper inserts virus onto the system
• Many categories of viruses, literally many
  thousands of viruses
• File
• Boot
• Macro
• Polymorphic
• Source code
• Encrypted
• Stealth
• Tunneling
• Multipartite
• Armored

32
Questions?
33
Part 3 Fun with Cryptography

• What is cryptography about?
• General Principles of Cryptography
• Basic Protocols
• Single-key cryptography
• Public-key cryptography
• An example...

34
Cryptography as a Security Tool

• Broadest security tool available
• Source and destination of messages cannot be
  trusted without cryptography
• Means to constrain potential senders (sources)
  and / or receivers (destinations) of messages
• Based on secrets (keys)

35
Principles

• Cryptography is about the exchange of messages
• The key to success is that all parties to an
  exchange trust that the system will both protect
  them from threats and accurately convey their
  message
• TRUST is essential

36
Therefore

• Algorithms must be public and verifiable
• We need to be able to estimate the risk of
  compromise
• The solution must practical for its users, and
  impractical for an attacker to break

37
Guidelines

• Cryptography is always based on algorithms which
  are orders of magnitude easier to compute in the
  forward (normal) direction than in the reverse
  (attack) direction.
• The attackers problem is never harder than
  trying all possible keys
• The more material the attacker has the easier his
  task

38
Example

• What is 314159265358979 ? 314159265358979?
• vs.
• What are prime factors of391257150641938709059482
  8508241?

39
Time marches on

• We must assume that there will always be
  improvements in computational power, mathematics
  and algorithms.
• Messages which hang around get less secure with
  time!
• Increases in computing power help the good guys
  and hurt the bad guys for new and short-lived
  messages

40
Caveat

• We cannot mathematically PROVE that the inverse
  operations are really as hard as they seem to
  beIt is all relative
• The Fundamental Tenet of Cryptography
• If lots of smart people have failed to solve a
  problem, it wont be solved (soon)

41
Secret key cryptography
K
K
f (T,K)
g (C,K)
C
T
T
Cleartext
Cleartext
Cyphertext
42
Secret Key Methods

• DES (56 bit key)
• IDEA (128 bit key)
• http//www.mediacrypt.com/community/index.asp
• Triple DES (three 56 bit keys)
• AES
• From NIST, 2000
• choice of key sizes up to 256 bits and more
• Commercial implementations available

43
Diffie Hellman
Alice
Agree on p,g
Bob
choose random A
choose random B
TA gA mod p
TB gB mod p
compute (TB)A
compute (TA)B
Shared secret key is gAB mod p
44
DH Problems

• Not in itself an encryption method we must
  still do a secret key encryption
• Subject to a man in the middle attack
• (Alice thinks she is talking to Bob, but actually
  Trudy is intercepting all of the messages and
  substitution her own)

45
RSA Public key cryptography
Key 1
Key 2
f ()
f ()
C
T
T
Cleartext
Cleartext
Cyphertext
Key 1 can be either a Public Key or a Private
Key. Key 2 is then the corresponding Private Key
or Public Key.
46
RSA Public Key Cryptography

• Rivest, Shamir and Adelman (1978)
• I can send messages that only you can read
• I can verify that you and only you could have
  sent a message
• I can use a trusted authority to distribute my
  public key
• The trusted authority is for your benefit!

47
RSA Details

• We will use the same operation to encrypt and
  decrypt
• To encrypt, we will use e as a key, to decrypt
  we will use d as a key
• e and d are inverses with respect to the chosen
  algorithm

48
RSA Details

• Choose n as the product of two large primes
• Finding the factors of a large number is
  mathematically hard (difficult)
• Finding primes is also hard
• Choose e to be a (fairly small) prime and compute
  d from e and the factors of n
• THROW AWAY THE FACTORS OF n!
• Publish two numbers, e (public key) and n

49
RSA Details

• Encryption Cyphertext (Cleartext)e mod n
• Decryption Cleartext (Cyphertext)d mod n
• Typical d will be on the order of 500 to 700 bits
• The cost of the algorithm is between 1? and 2 ?
  the size of n,
• Each operation is a giant shift and add (multiply
  by a power of 2)

50
RSA Problems

• It is much more costly than typical secret-key
  methods ?
• Use RSA to hide (i.e., encrypt) a secret key,
• Encrypt the message with the secret key and
  append/prefix the encrypted key
• Requires a Public Key Infrastructure for
  effective key generation and distribution
• Chain of trust thing again!

51
Message Digests (aka Digital Signatures)

• A message digest is a non-reversable algorithm
  which reduces a message to a fixed-length
  summary
• The summary has the property that a change to the
  original will produce a new summary
• The probability that the new summary is the same
  as the old should be 1/(size of digest)
• Silbershatz, p. 582 (15.4.1.3)

52
Message Digests (2)

• There are several good (but possibly no perfect)
  message digest algorithms
• MD5 is probably the most common one in use 128
  bit digest
• has known weaknesses
• SHA-1 160 bit digest (current best choice)
• Another product of NIST

53
Conclusion

• Protection in OS is
• Difficult
• Important
• Security is needed for
• Authentication of users
• Validation of communication

54
Reading Assignment

• Silbershatz, Chapter 15