CSCI283/172 Fall 2006

1
Lock-Key and Ring-Based Access Control

• CSCI283/172 Fall 2006
• GWU
• Sources
• Memons notes, Brooklyn Poly
• Bishops Text, Chapter 15
• Bishops slides, Chapter 15
• Text by Pfleeger and Pfleeger, Chapter 3

2
Access Control Mechanisms

• Access Control Matrix
• Access Control List
• Capability based access control
• Lock and Key based access control.
• Rings-based access control

3
Access control with Locks and Keys

• Combines features of ACLs and capabilities.
• A piece of information (lock) associated with the
  object.
• Another piece of information (key) associated
  with subjects authorized to access the object.
• This can be dynamic
• ACLs, C-Lists static and must be manually changed
• Locks and keys can change based on system
  constraints, other factors (not necessarily
  manual).

4
Cryptographic Implementation

• Enciphering key is lock deciphering key is key
• Encipher object o store Ek(o)
• Use subjects key k? to compute Dk?(Ek(o))
• Any of n can access o store
• o? (E1(o), , En(o))
• Requires consent of all n to access o store
• o? (E1(E2((En(o))))
• IBMs Cryptolope, Intertrusts Digibox for
  digital media
• encrypt object with key K
• encrypt K with users public key
• Associated license determines rights, enforced by
  secure viewer

5
Locks and Keys in IBM 370

• Each process assigned access key and each page a
  storage key and fetch bit.
• If fetch bit is cleared, only read access
  allowed.
• Process with access key 0 can write any page with
  fetch bit set.
• If storage key matches access key of process then
  process allowed to write to page.
• If no match and access key not 0, then no access
  allowed.

6
Type checking

• Type checking controls access based on type of
  subject and object.
• It is a kind of lock and key access with the
  pieces of information being the type.
• Simplest example of type checking is
  distinguishing instructions from data. Execute
  allowed only on instructions and read and write
  only on data.
• One approach to limit buffer overflow problem is
  to mark stack memory as data.

7
Buffer overflow

• Anecdotal notes suggest buffer overflows were
  known since sixties
• Take advantage of the lack of array bounds
  checking in C and C (and other languages) to
  transfer control to malicious code.
• Despite the fact that this vulnerability is
  well-known and preventable, buffer overflow
  attacks still prevalent

8
Procedure-oriented access control

• A procedure controls access to objects
• legitimate access to object only through the
  procedure
• the procedure performs its own check re
  legitimacy of call
• Inefficient, but more secure because only
  procedure need know the means of implementing the
  object and its access
• E.g. access to multimedia objects using an
  encryption key when OS requires only password

9
Threshold Secret Sharing

• A bank allows its central safe to be opened by
  any three of its top seven officers. Fewer than
  three of the top seven may not open it.
• A declaration of war requires the agreement of at
  least five of the top seven officials of a
  countrys government. No fewer will do.
• Access to the grades of CS283/172 requires the
  presence of two TAs or the course instructor. No
  one TA can access these.

10
Sharing Secrets

• Implements separation of privilege
• Use (t, n)-threshold scheme
• Secret divided into n parts or shares (shadows)
• Any t shares sufficient to derive original data
• Or-access and and-access can do this
• Increases the number of representations of data
  rapidly as n, t grow
• Cryptographic approaches more common

11
Shamirs Scheme

• Goal use (t, n)-threshold scheme to share
  cryptographic key encoding data
• Based on Lagrange polynomials
• Idea take polynomial p(x) of degree t1, set
  constant term (p(0)) to key
• Compute value of p at n points, excluding x 0
• By algebra, need values of p at any t distinct
  points to derive polynomial, and hence constant
  term (key)

12
Example generating shares

• Secret S 3
• (t, n) (2, 4) threshold scheme
• S, n, lt p 7
• Any polynomial f(x) of degree t-1 1
• f(0) S 3
• 4x 3 mod 7
• Shadows any four distinct points on the curve
• Example f(1), f(2), f(3), f(4)

13
Example reconstructing secret

• Any two values will completely define a
  polynomial of degree one Ax b mod 7
• f(1) 0, f(2) 4, f(3) 1, f(4) 5
• 1, 2 A b 0, 2A b 4 A 4, b3 S
• 2, 3 2A b 4, 3Ab 1 A-3 4, b3S
• 1, 4 Ab 0, 4Ab5 3A 5 mod 7, A 3-1 5
  25 4
• And so on

14
Example One value says nothing

• f(1) 0, f(2) 4, f(3) 1, f(4) 5
• Ab 0
• b, the secret, can be anything

15
Example generating shares t gt 2

• Secret S 3
• (t, n) (3, 4) threshold scheme
• S, n, lt p 7
• Any polynomial f(x) of degree t-1 2
• f(0) S 3
• x2 4x 3 mod 7
• Shadows any four distinct points on the curve
• Example f(1), f(2), f(3), f(4)

16
Secret Sharing Reconstruction

• Given shares (xi, f(xi)yi), find f(0)
• Lagrange Interpolation
• f(x) ? fj(x)
• fj (x) yj ?k? j (x-xk)/(xj-xk)
• Find f(0)

17
Example reconstructing secrettgt2

• Any three values will completely define a
  polynomial of degree two
• f(1) 1, f(2) 1, f(3) 3, f(4) 0
• Lagrangian interpolation by 1, 2, 4
• 1 (x-2/1-2)(x-4/1-4) 1 (x-1/2-1)(x-4/2-4)
  0(x-1/4-1)(x-2/4-2)
• 1(-1)(-5)(x-2)(x-4) (1)(1)(-4)(x-1)(x-4)
• (x-4)(5x-10-4x4) (x-4)(x-6) x2 -10x 24
  mod 7 x2 4x 3

18
Secret Sharing Reconstruction

• Given shares (xi, f(xi)yi), find f(0)
• Lagrange Interpolation
• f(x) ? fj(x)
• fj (x) yj ?k? j (x-xk)/(xj-xk)
• Find f(0)

19
PACLs

• Propagated Access Control List (List of subjects
  who can access the data)
• Creator kept with PACL, copies
• Only owner can change PACL
• Subject reads object objects PACL associated
  with subject
• Subject writes object subjects PACL associated
  with object
• Notation PACLs means s created object PACL(e)
  is PACL associated with entity e

20
Multiple Creators

• Betty reads Anns file dates
• PACL(Betty) PACLBetty ? PACL(dates)
• PACLBetty ? PACLAnn
• Betty creates file dc
• PACL(dc) PACLBetty ? PACLAnn
• PACLBetty allows Char to access objects, but
  PACLAnn does not both allow June to access
  objects
• June can read dc
• Char cannot read dc

21
Ring-Based Access Control

• Process (segment) accesses
• another segment
• Read
• Execute
• Gate is an entry point for
• calling segment
• Rights
• r read
• w write
• a append
• e execute

Privileges increase

n
0
1
22
Reading/Writing/Appending

• Procedure executing in ring r
• Data segment with access bracket (a1, a2)
• Mandatory access rule
• r a1 allow access
• a1 lt r a2 allow r access not w, a access
• a2 lt r deny all access

23
Executing

• Procedure executing in ring r
• Call procedure in segment with access bracket
  (a1, a2) and call bracket (a2, a3)
• Often written (a1, a2 , a3 )
• Mandatory access rule
• r lt a1 allow access ring-crossing fault
• a1 r a2 allow access no ring-crossing fault
• a2 lt r a3 allow access if through valid gate
• a3 lt r deny all access

24
Versions

• Multics
• 8 rings (from 0 to 7)
• Digital Equipments VAX
• 4 levels of privilege user, monitor, executive,
  kernel
• Older systems
• 2 levels of privilege user, supervisor

25
Buffer overflow

• Anecdotal notes suggest buffer overflows were
  known since sixties
• Take advantage of the lack of array bounds
  checking in C and C (and other languages) to
  transfer control to malicious code.
• Despite the fact that this vulnerability is
  well-known and preventable, buffer overflow
  attacks still prevalent

26
Buffer overflow

• Over 50 of the major security bugs leading to
  CERT Coordination Center advisories in 1999

27
Why is buffer overflow prevalent?

• C/C is inherently unsafe?
• C/C library contains many unsafe functions
• Pre, post conditions to these functions are not
  well understood
• Lack of bound checking
• Programmers often forget to do bound checking
• C/C dont do bound checking, unlike Java
• Unsafe functions lack bound checking
• Code reuse
• Many unsafe libraries are heavily reused e.g. libc

28
Buffer overflow

• char sample10
• sample10 A
• Or
• for (i0 ilt10 i) samplei A
• samplei B
• Can overflow into user data, user program code,
  system data, system program code
• Leads to computing with a faulty value or
  execution of an improper/unintended instruction

29
General effects of buffer overflow

• No effect (if overwritten variables are not
  subsequently accessed)
• Program crash
• Strange output (possibly difficult to reproduce)
• Malicious effects
• if buffer overflow is carefully exploited to
  transfer control to malicious code
• Note that buffer overflows may be difficult to
  detect with conventional software testing.

30
Exploiting buffer overflow

• Overflow a buffer allocated on the stack or on
  the heap in a way that causes the value of some
  important variable to change
• e.g. flag indicating whether program can access
  private files
• (harder w/ heap (dynamically allocated) allocated
  arrays, since memory map cant be predicted.)
• Smash the stack
• Overflow buffer allocated on the stack to change
  return pointer to the address of some malicious
  code

31
Smashing the stack

• Find a stack-allocated buffer such that overflow
  will allow return address to be overwritten.
• Requires detailed understanding of activation
  record layout
• Use debugger or modify code to dump relevant
  addresses and their contents
• Place hostile code in memory.
• Write over return address to cause jump to
  hostile code.

32
Popular Targets

• Processes that run with higher privileges
• Many UNIX functions need higher privileges to do
  things like writing to mail queue or opening a
  socket
• Ordinary user programs may be temporarily granted
  higher privileges to invoke such functions
• Transfer control to code that spawns a shell
• Then use the shell (running with root privileges)
  to do whatever you want.

33
Buffer overflow defenses

• Do bound checking where necessary
• The overhead is small compared to the risks
• Write daemons in a type-safe language like Java
• Using dynamic memory(heap) for buffers does not
  solve the problem. Only makes it harder to
  exploit
• Integrate security into software developments
• Code reviews
• Testing
• Checking security of added components

34
Buffer overflow defenses

• Non-executable buffers
• Make data segment of address space
  non-executable. Although this is how older
  operating systems were designed newer versions of
  Unix and Windows make the data segment executable
  for performance optimization
• Bound checking by compilers
• Compilers can insert bound checking code at
  compile time e.g. Compaq C Compiler

35
Buffer overflow defenses

• Type-safe Languages
• If type-safe operations can be performed on a
  given variables then arbitrary changes cannot be
  used to execute code
• Stack integrity checks
• StackGuard Compiler generates integrity checks
  on activation records
• PointGuard Compiler generates integrity checks
  on instruction pointer