Information Security Text Book

CIS 739 COMPUTER SECURITY
November 1, 2004
Introduction to Computer Security 2004 Matt Bishop
Slide #1-1
Chapter 1: Introduction
Components of computer security Threats Policies and mechanisms The role of trust Assurance Operational Issues Human Issues
Introduction to Computer Security 2004 Matt Bishop Slide #1-2
November 1, 2004
Basic Components
Confidentiality
Keeping data and resources hidden
Integrity
Data integrity (integrity) Origin integrity (authentication)
Availability
Enabling access to data and resources
November 1, 2004 Introduction to Computer Security 2004 Matt Bishop Slide #1-3
Classes of Threats
Disclosure
Snooping
Deception
Modification, spoofing, repudiation of origin, denial of receipt
Disruption
Modification
Usurpation
Modification, spoofing, delay, denial of service
Policies and Mechanisms

Policy says what is, and is not, allowed
This defines security for the site/system/etc.
Mechanisms enforce policies Composition of policies

If policies conflict, discrepancies may create security vulnerabilities
November 1, 2004
Slide #1-5
Goals of Security
Prevention
Prevent attackers from violating security policy
Detection
Detect attackers violation of security policy
Recovery
Stop attack, assess and repair damage Continue to function correctly even if attack succeeds
Trust and Assumptions

Underlie all aspects of security Policies
Unambiguously partition system states Correctly capture security requirements
Mechanisms
Assumed to enforce policy Support mechanisms work correctly
Types of Mechanisms
secure
precise
broad
set of reachable states

November 1, 2004 Introduction to Computer Security 2004 Matt Bishop
set of secure states

Slide #1-8
Assurance
Specification
Requirements analysis Statement of desired functionality
Design
How system will meet specification
Implementation
Programs/systems that carry out design
Operational Issues
Cost-Benefit Analysis
Is it cheaper to prevent or recover?
Risk Analysis
Should we protect something? How much should we protect this thing?
Laws and Customs

Are desired security measures illegal? Will people do them?
Human Issues
Organizational Problems
Power and responsibility Financial benefits
People problems
Outsiders and insiders Social engineering
November 1, 2004
Slide #1-11
Tying Together
Threats Policy Specification Design Implementation Operation
Key Points
Policy defines security, and mechanisms enforce security
Confidentiality Integrity Availability
Trust and knowing assumptions Importance of assurance The human factor

Chapter 2: Access Control Matrix

Overview Access Control Matrix Model Protection State Transitions
Commands Conditional Commands
November 1, 2004
Slide #1-14
Overview
Protection state of system
Describes current settings, values of system relevant to protection
Access control matrix

Describes protection state precisely Matrix describing rights of subjects State transitions change elements of matrix
Description
objects (entities) o1 om s1 sn subjects s1 s2 sn
November 1, 2004
Subjects S = { s1,,sn } Objects O = { o1,,om } Rights R = { r1,,rk } Entries A[si, oj] R A[si, oj] = { rx, , ry } means subject si has rights rx, , ry over object oj
Slide #1-16
Example 1
Processes p, q Files f, g Rights r, w, x, a, o f g p rwo r q a ro
November 1, 2004
p rwxo r
q w rwxo
Slide #1-17
Example 2
Procedures inc_ctr, dec_ctr, manage Variable counter Rights +, , call counter inc_ctr dec_ctr inc_ctr + dec_ctr manage call call
manage
call
Slide #1-18
State Transitions
Change the protection state of system | represents transition
Xi | Xi+1: command moves system from state Xi to Xi+1 Xi | * Xi+1: a sequence of commands moves system from state Xi to Xi+1
Commands often called transformation procedures

Primitive Operations
create subject s; create object o
Creates new row, column in ACM; creates new column in ACM
destroy subject s; destroy object o

Deletes row, column from ACM; deletes column from ACM
enter r into A[s, o]

Adds r rights for subject s over object o
delete r from A[s, o]

Removes r rights from subject s over object o
November 1, 2004
Slide #1-20
Creating File
Process p creates file f with r and w permission
co m m and create f i l e(p ,f ) create object f ; enter own in to A[p, f ] ; enter rin t o A[p,f ] ; enter w int o A[p,f ] ; end
November 1, 2004
Slide #1-21
Mono-Operational Commands
Make process p the owner of file g
co m m and makeowner ( p, g ) enter own in to A[p, g] ; end
Mono-operational command
Single primitive operation in this command
November 1, 2004
Slide #1-22
Conditional Commands
Let p give q r rights over f, if p owns f
co m m and grant read f i l e1(p,f ,q ) i f own in A[p, f ] then enter rin t o A[q,f ] ; end
Mono-conditional command
Single condition in this command
November 1, 2004
Slide #1-23
Multiple Conditions
Let p give q r and w rights over f, if p owns f and p has c rights over q
co m m and grant read f i l e2(p,f ,q ) i f own in A[p, f ] and c in A[p, q] then enter rin t o A[q,f ] ; enter w int o A[q,f ] ; end
November 1, 2004
Slide #1-24
Key Points
Access control matrix simplest abstraction mechanism for representing protection state Transitions alter protection state 6 primitive operations alter matrix
Transitions can be expressed as commands composed of these operations and, possibly, conditions
Chapter 3: Foundational Results

Overview Harrison-Ruzzo-Ullman result
Corollaries
November 1, 2004
Slide #1-26
Overview
Safety Question HRU Model
November 1, 2004
Slide #1-27
What Is Secure?
Adding a generic right r where there was not one is leaking If a system S, beginning in initial state s0, cannot leak right r, it is safe with respect to the right r.
November 1, 2004
Slide #1-28
Safety Question
Does there exist an algorithm for determining whether a protection system S with initial state s0 is safe with respect to a generic right r?
Here, safe = secure for an abstract model
November 1, 2004
Slide #1-29
Mono-Operational Commands
Answer: yes Sketch of proof:
Consider minimal sequence of commands c1, , ck to leak the right. Can omit delete, destroy Can merge all creates into one Worst case: insert every right into every entry; with s subjects and o objects initially, and n rights, upper bound is k n(s+1)(o+1)
General Case
Answer: no Sketch of proof:
Reduce halting problem to safety problem Turing Machine review: Infinite tape in one direction States K, symbols M; distinguished blank b Transition function (k, m) = (k, m, L) means in state k, symbol m on tape location replaced by symbol m, head moves to left one square, and enters state k Halting state is qf; TM halts when it enters this state
Mapping
1 2 3 4
B C D s1 head Current state is k s2 s3 s4
s1 A
s2 own B
s3
s4
own Ck own D end
November 1, 2004
Slide #1-32
Mapping
1 2 3 4
B X D head s1 s2 s3 s4
s1 A
s2 own B
s3
s4
own X own D k1 end
After (k, C) = (k1, X, R) where k is the current state and k1 the next state
November 1, 2004
Slide #1-33
Command Mapping
(k, C) = (k1, X, R) at intermediate becomes co m m and ck,C(s3 ,s4) i f own in A[s3, s4] and k i n A[s3,s3 ] and C in A[s3,s3] then ,s3] ; delete k f r o m A[ s3 delete C f r o m A[ s3 ,s3] ; enter X in t o A[s3,s3 ] ; enter k1 into A [ s4,s4 ] ; end
Mapping
1 2 3 4 5
B X Y
b head s1 s2 s3 s4 s5
s1 A
s2 own B
s3
s4
s5
own X own Y own b k2 end

Slide #1-35
After (k1, D) = (k2, Y, R) where k1 is the current state and k2 the next state
November 1, 2004
Command Mapping
(k1, D) = (k2, Y, R) at end becomes s5) co m m and cr i gh tmos tk,C(s4, s4 ] and k1 in A [s4 ,s4] i f end in A [s4, s4 ] and D in A [s4, then ] ; delete end f r o m A[s4,s4 ; create subject s5 s5 ] ; enter own into A [s4, s5 ] ; enter end into A [s5, rom A[s4, s4 ] ; delete k1 f s4 ] ; delete D f rom A[s4, ; enter Y into A[s4,s4] [s5 ,s5] ; enter k2 into A end
Rest of Proof
Protection system exactly simulates a TM
Exactly 1 end right in ACM 1 right in entries corresponds to state Thus, at most 1 applicable command
If TM enters state qf, then right has leaked If safety question decidable, then represent TM as above and determine if qf leaks
Implies halting problem decidable
Conclusion: safety question undecidable

Other Results
Set of unsafe systems is recursively enumerable Delete create primitive; then safety question is complete in P-SPACE Delete destroy, delete primitives; then safety question is undecidable Systems are monotonic Safety question for monoconditional, monotonic protection systems is decidable Safety question for monoconditional protection systems with create, enter, delete (and no destroy) is decidable.
Key Points
Safety problem undecidable Limiting scope of systems can make problem decidable
November 1, 2004
Slide #1-39
Chapter 4: Security Policies

Overview The nature of policies
What they cover Policy languages
The nature of mechanisms

Types
Underlying both
Trust
Overview
Overview Policies Trust Nature of Security Mechanisms Example Policy
November 1, 2004
Slide #1-41
Security Policy
Policy partitions system states into:
Authorized (secure)
These are states the system can enter
Unauthorized (nonsecure)
If the system enters any of these states, its a security violation
Secure system
Starts in authorized state Never enters unauthorized state
Confidentiality
X set of entities, I information I has confidentiality property with respect to X if no x X can obtain information from I I can be disclosed to others Example:
X set of students I final exam answer key I is confidential with respect to X if students cannot obtain final exam answer key
Integrity
X set of entities, I information I has integrity property with respect to X if all x X trust information in I Types of integrity:
trust I, its conveyance and protection (data integrity) I information about origin of something or an identity (origin integrity, authentication) I resource: means resource functions as it should (assurance)
Availability
X set of entities, I resource I has availability property with respect to X if all x X can access I Types of availability:
traditional: x gets access or not quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved
November 1, 2004
Slide #1-45
Policy Models
Abstract description of a policy or class of policies Focus on points of interest in policies
Security levels in multilevel security models Separation of duty in Clark-Wilson model Conflict of interest in Chinese Wall model
November 1, 2004
Slide #1-46
Types of Security Policies

Military (governmental) security policy
Policy primarily protecting confidentiality
Commercial security policy

Policy primarily protecting integrity
Confidentiality policy
Policy protecting only confidentiality
Integrity policy
Policy protecting only integrity
Integrity and Transactions

Begin in consistent state
Consistent defined by specification
Perform series of actions (transaction)

Actions cannot be interrupted If actions complete, system in consistent state If actions do not complete, system reverts to beginning (consistent) state
Trust
Administrator installs patch 1. Trusts patch came from vendor, not tampered with in transit 2. Trusts vendor tested patch thoroughly 3. Trusts vendors test environment corresponds to local environment 4. Trusts patch is installed correctly
Trust in Formal Verification

Gives formal mathematical proof that given input i, program P produces output o as specified Suppose a security-related program S formally verified to work with operating system O What are the assumptions?
Trust in Formal Methods

1. Proof has no errors
Bugs in automated theorem provers
2. Preconditions hold in environment in which S is to be used 3. S transformed into executable S whose actions follow source code
Compiler bugs, linker/loader/library problems Hardware bugs (Pentium f00fbug, for example)
4. Hardware executes S as intended
November 1, 2004
Types of Access Control

Discretionary Access Control (DAC, IBAC)
individual user sets access control mechanism to allow or deny access to an object
Mandatory Access Control (MAC)

system mechanism controls access to object, and individual cannot alter that access
Originator Controlled Access Control (ORCON)

originator (creator) of information controls who can access information
Question
Policy disallows cheating
Includes copying homework, with or without permission
CS class has students do homework on computer Anne forgets to read-protect her homework file Bill copies it Who cheated?
Anne, Bill, or both?
November 1, 2004
Slide #1-53
Answer Part 1
Bill cheated
Policy forbids copying homework assignment Bill did it System entered unauthorized state (Bill having a copy of Annes assignment)
If not explicit in computer security policy, certainly implicit

Not credible that a unit of the university allows something that the university as a whole forbids, unless the unit explicitly says so
Answer Part 2
Anne didnt protect her homework
Not required by security policy
She didnt breach security If policy said students had to read-protect homework files, then Anne did breach security
She didnt do this
Mechanisms
Entity or procedure that enforces some part of the security policy
Access controls (like bits to prevent someone from reading a homework file) Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems
November 1, 2004
Slide #1-56
Example English Policy

Computer security policy for academic institution
Institution has multiple campuses, administered from central office Each campus has its own administration, and unique aspects and needs
Authorized Use Policy Electronic Mail Policy

Authorized Use Policy

Intended for one campus (Davis) only Goals of campus computing
Underlying intent
Procedural enforcement mechanisms

Warnings Denial of computer access Disciplinary action up to and including expulsion
Written informally, aimed at user community
November 1, 2004
Slide #1-58
Electronic Mail Policy

Systemwide, not just one campus Three parts
Summary Full policy Interpretation at the campus
November 1, 2004
Slide #1-59
Summary
Warns that electronic mail not private
Can be read during normal system administration Can be forged, altered, and forwarded
Unusual because the policy alerts users to the threats

Usually, policies say how to prevent problems, but do not define the threats
Summary
What users should and should not do
Think before you send Be courteous, respectful of others Dont nterfere with others use of email
Personal use okay, provided overhead minimal Who it applies to

Problem is UC is quasi-governmental, so is bound by rules that private companies may not be Educational mission also affects application
November 1, 2004
Slide #1-61
Full Policy
Context
Does not apply to Dept. of Energy labs run by the university Does not apply to printed copies of email
Other policies apply here
E-mail, infrastructure are university property

Principles of academic freedom, freedom of speech apply Access without users permission requires approval of vice chancellor of campus or vice president of UC If infeasible, must get permission retroactively
November 1, 2004
Slide #1-62
Uses of E-mail
Anonymity allowed
Exception: if it violates laws or other policies
Cant interfere with others use of e-mail

No spam, letter bombs, e-mailed worms, etc.
Personal e-mail allowed within limits

Cannot interfere with university business Such e-mail may be a university record subject to disclosure
Security of E-mail
University can read e-mail
Wont go out of its way to do so Allowed for legitimate business purposes Allowed to keep e-mail robust, reliable
Archiving and retention allowed

May be able to recover e-mail from end system (backed up, for example)
Implementation
Adds campus-specific requirements and procedures
Example: incidental personal use not allowed if it benefits a non-university organization Allows implementation to take into account differences between campuses, such as self-governance by Academic Senate
Procedures for inspecting, monitoring, disclosing e-mail contents Backups

Key Points
Policies describe what is allowed Mechanisms control how policies are enforced Trust underlies everything
November 1, 2004
Slide #1-66
Chapter 5: Confidentiality Policies

Overview
What is a confidentiality model
Bell-LaPadula Model
General idea Informal description of rules
November 1, 2004
Slide #1-67
Overview
Goals of Confidentiality Model Bell-LaPadula Model
Informally Example Instantiation
November 1, 2004
Slide #1-68
Confidentiality Policy
Goal: prevent the unauthorized disclosure of information
Deals with information flow Integrity incidental
Multi-level security models are best-known examples

Bell-LaPadula Model basis for many, or most, of these
Bell-LaPadula Model, Step 1

Security levels arranged in linear ordering
Top Secret: highest Secret Confidential Unclassified: lowest
Levels consist of security clearance L(s)

Objects have security classification L(o)
Example
security level Top Secret Secret Confidential Unclassified subject Tamara Samuel Claire Ulaley object Personnel Files E-Mail Files Activity Logs Telephone Lists
Tamara can read all files Claire cannot read Personnel or E-Mail Files Ulaley can only read Telephone Lists
Reading Information
Information flows up, not down
Reads up disallowed, reads down allowed
Simple Security Condition (Step 1)

Subject s can read object o iff L(o) L(s) and s has permission to read o
Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
Sometimes called no reads up rule

Writing Information
Writes up allowed, writes down disallowed
*-Property (Step 1)
Subject s can write object o iff L(s) L(o) and s has permission to write o
Sometimes called no writes down rule

Basic Security Theorem, Step 1

If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 1, and the *property, step 1, then every state of the system is secure
Proof: induct on the number of transitions
November 1, 2004
Slide #1-74
Bell-LaPadula Model, Step 2

Expand notion of security level to include categories Security level is (clearance, category set) Examples
( Top Secret, { NUC, EUR, ASI } ) ( Confidential, { EUR, ASI } ) ( Secret, { NUC, ASI } )
Levels and Lattices

(A, C) dom (A, C) iff A A and C C Examples
(Top Secret, {NUC, ASI}) dom (Secret, {NUC}) (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR}) (Top Secret, {NUC}) dom (Confidential, {EUR})
Let C be set of classifications, K set of categories. Set of security levels L = C K, dom form lattice
lub(L) = (max(A), C) glb(L) = (min(A), )
Levels and Ordering

Security levels partially ordered
Any pair of security levels may (or may not) be related by dom
dominates serves the role of greater than in step 1

greater than is a total ordering, though
November 1, 2004
Slide #1-77
Reading Information
Reads up disallowed, reads down allowed
Simple Security Condition (Step 2)

Subject s can read object o iff L(s) dom L(o) and s has permission to read o
Sometimes called no reads up rule

Writing Information
Writes up allowed, writes down disallowed
*-Property (Step 2)
Subject s can write object o iff L(o) dom L(s) and s has permission to write o
Sometimes called no writes down rule

Basic Security Theorem, Step 2

If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 2, and the *-property, step 2, then every state of the system is secure
Proof: induct on the number of transitions In actual Basic Security Theorem, discretionary access control treated as third property, and simple security property and *-property phrased to eliminate discretionary part of the definitions but simpler to express the way done here.
Problem
Colonel has (Secret, {NUC, EUR}) clearance Major has (Secret, {EUR}) clearance
Major can talk to colonel (write up or read down) Colonel cannot talk to major (read up or write down)
Clearly absurd!
Solution
Define maximum, current levels for subjects
maxlevel(s) dom curlevel(s)
Example
Treat Major as an object (Colonel is writing to him/her) Colonel has maxlevel (Secret, { NUC, EUR }) Colonel sets curlevel to (Secret, { EUR }) Now L(Major) dom curlevel(Colonel)
Colonel can write to Major without violating no writes down
Does L(s) mean curlevel(s) or maxlevel(s)?

Formally, we need a more precise notation
DG/UX System
Provides mandatory access controls
MAC label identifies security level Default labels, but can define others
Initially
Subjects assigned MAC label of parent
Initial label assigned to user, kept in Authorization and Authentication database
Object assigned label at creation

Explicit labels stored as part of attributes Implicit labels determined from parent directory
MAC Regions
A&A database, audit Hierarchy levels VP1 VP2 VP3 VP4 VP5 User data and applications Site executables Trusted data Virus Prevention Region Executables not part of the TCB Executables part of theTCB Reserved for future use Categories Administrative Region User Region
IMPL_HI is maximum (least upper bound) of all levels IMPL_LO is minimum (greatest lower bound) of all levels
Directory Problem
Process p at MAC_A tries to create file /tmp/x /tmp/x exists but has MAC label MAC_B
Assume MAC_B dom MAC_A
Create fails
Now p knows a file named x with a higher label exists
Fix: only programs with same MAC label as directory can create files in the directory
Now compilation wont work, mail cant be delivered
Multilevel Directory
Directory with a set of subdirectories, one per label
Not normally visible to user p creating /tmp/x actually creates /tmp/d/x where d is directory corresponding to MAC_A All ps references to /tmp go to /tmp/d
p cds to /tmp/a, then to ..

System call stat(., &buf) returns inode number of real directory System call dg_stat(., &buf) returns inode of /tmp
Object Labels
Requirement: every file system object must have MAC label 1. Roots of file systems have explicit MAC labels
If mounted file system has no label, it gets label of mount point
2. Object with implicit MAC label inherits label of parent

Object Labels
Problem: object has two names
/x/y/z, /a/b/c refer to same object y has explicit label IMPL_HI b has explicit label IMPL_B
Case 1: hard link created while file system on DG/UX system, so 3. Creating hard link requires explicit label
If implicit, label made explicit Moving a file makes label explicit
November 1, 2004
Object Labels
Case 2: hard link exists when file system mounted
No objects on paths have explicit labels: paths have same implicit labels An object on path acquires an explicit label: implicit label of child must be preserved
so 4. Change to directory label makes child labels explicit before the change
Object Labels
Symbolic links are files, and treated as such, so 5. When resolving symbolic link, label of object is label of target of the link
System needs access to the symbolic link itself
November 1, 2004
Slide #1-90
Using MAC Labels

Simple security condition implemented *-property not fully implemented
Process MAC must equal object MAC Writing allowed only at same security level
Overly restrictive in practice
November 1, 2004
Slide #1-91
MAC Tuples
Up to 3 MAC ranges (one per region) MAC range is a set of labels with upper, lower bound
Upper bound must dominate lower bound of range
Examples
1. [(Secret, {NUC}), (Top Secret, {NUC})] 2. [(Secret, ), (Top Secret, {NUC, EUR, ASI})] 3. [(Confidential, {ASI}), (Secret, {NUC, ASI})]
MAC Ranges
1. 2. 3. [(Secret, {NUC}), (Top Secret, {NUC})] [(Secret, ), (Top Secret, {NUC, EUR, ASI})] [(Confidential, {ASI}), (Secret, {NUC, ASI})] (Top Secret, {NUC}) in ranges 1, 2 (Secret, {NUC, ASI}) in ranges 2, 3 [(Secret, {ASI}), (Top Secret, {EUR})] not valid range
as (Top Secret, {EUR}) dom (Secret, {ASI})
November 1, 2004
Objects and Tuples

Objects must have MAC labels
May also have MAC label If both, tuple overrides label
Example
Paper has MAC range: [(Secret, {EUR}), (Top Secret, {NUC, EUR})]
November 1, 2004
Slide #1-94
MAC Tuples
Process can read object when:
Object MAC range (lr, hr); process MAC label pl pl dom hr
Process MAC label grants read access to upper bound of range
Example
Peter, with label (Secret, {EUR}), cannot read paper
(Top Secret, {NUC, EUR}) dom (Secret, {EUR})
Paul, with label (Top Secret, {NUC, EUR, ASI}) can read paper
(Top Secret, {NUC, EUR, ASI}) dom (Top Secret, {NUC, EUR})
MAC Tuples
Process can write object when:
Object MAC range (lr, hr); process MAC label pl pl (lr, hr)
Process MAC label grants write access to any label in range
Example
Peter, with label (Secret, {EUR}), can write paper
(Top Secret, {NUC, EUR}) dom (Secret, {EUR}) and (Secret, {EUR}) dom (Secret, {EUR})
Paul, with label (Top Secret, {NUC, EUR, ASI}), cannot read paper
(Top Secret, {NUC, EUR, ASI}) dom (Top Secret, {NUC, EUR})
Key Points
Confidentiality models restrict flow of information Bell-LaPadula models multilevel security
Cornerstone of much work in computer security
November 1, 2004
Slide #1-97
Chapter 6: Integrity Policies

Overview Requirements Bibas models Clark-Wilson model
November 1, 2004
Slide #1-98
Overview
Requirements
Very different than confidentiality policies
Bibas model Clark-Wilson model
November 1, 2004
Slide #1-99
Requirements of Policies
1. 2. Users will not write their own programs, but will use existing production programs and databases. Programmers will develop and test programs on a non-production system; if they need access to actual data, they will be given production data via a special process, but will use it on their development system. A special process must be followed to install a program from the development system onto the production system. The special process in requirement 3 must be controlled and audited. The managers and auditors must have access to both the system state and the system logs that are generated.
3. 4. 5.
November 1, 2004
Slide #1-100
Biba Integrity Model

Set of subjects S, objects O, integrity levels I, relation I I holding when second dominates first min: I I I returns lesser of integrity levels i: S O I gives integrity level of entity r: S O means s S can read o O w, x defined similarly
Intuition for Integrity Levels

The higher the level, the more confidence
That a program will execute correctly That data is accurate and/or reliable
Note relationship between integrity and trustworthiness Important point: integrity levels are not security levels
Bibas Model
Similar to Bell-LaPadula model
1. 2. 3. s S can read o O iff i(s) i(o) s S can write to o O iff i(o) i(s) s1 S can execute s2 S iff i(s2) i(s1)
Add compartments and discretionary controls to get full dual of Bell-LaPadula model Information flow result holds
Different proof, though
Actually the strict integrity model of Bibas set of models

LOCUS and Biba

Goal: prevent untrusted software from altering data or other software Approach: make levels of trust explicit
credibility rating based on estimate of softwares trustworthiness (0 untrusted, n highly trusted) trusted file systems contain software with a single credibility level Process has risk level or highest credibility level at which process can execute Must use run-untrusted command to run software at lower credibility level
Clark-Wilson Integrity Model

Integrity defined by a set of constraints
Data in a consistent or valid state when it satisfies these
Example: Bank
D todays deposits, W withdrawals, YB yesterdays balance, TB todays balance Integrity constraint: D + YB W
Well-formed transaction move system from one consistent state to another Issue: who examines, certifies transactions done correctly?
Entities
CDIs: constrained data items
Data subject to integrity controls
UDIs: unconstrained data items

Data not subject to integrity controls
IVPs: integrity verification procedures

Procedures that test the CDIs conform to the integrity constraints
TPs: transaction procedures

Procedures that take the system from one valid state to another
Certification Rules 1 and 2

CR1 When any IVP is run, it must ensure all CDIs are in a valid state CR2 For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state
Defines relation certified that associates a set of CDIs with a particular TP Example: TP balance, CDIs accounts, in bank example
Enforcement Rules 1 and 2

ER1 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI. ER2 The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI.
System must maintain, enforce certified relation System must also restrict access based on user ID (allowed relation)
November 1, 2004
Slide #1-108
Users and Rules

CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty. ER3 The system must authenticate each user attempting to execute a TP
Type of authentication undefined, and depends on the instantiation Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs)
Logging
CR4 All TPs must append enough information to reconstruct the operation to an append-only CDI.
This CDI is the log Auditor needs to be able to determine what happened during reviews of transactions
November 1, 2004
Slide #1-110
Handling Untrusted Input

CR5 Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the UDI. The transformation either rejects the UDI or transforms it into a CDI.
In bank, numbers entered at keyboard are UDIs, so cannot be input to TPs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI
Separation of Duty In Model

ER4 Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated with that TP, may ever have execute permission with respect to that entity.
Enforces separation of duty with respect to certified and allowed relations
Comparison With Requirements

1. Users cant certify TPs, so CR5 and ER4 enforce this 2. Procedural, so model doesnt directly cover it; but special process corresponds to using TP
No technical controls can prevent programmer from developing program on production system; usual control is to delete software tools
3. TP does the installation, trusted personnel do certification

Comparison With Requirements

4. CR4 provides logging; ER3 authenticates trusted personnel doing installation; CR5, ER4 control installation procedure
New program UDI before certification, CDI (and TP) after
5. Log is CDI, so appropriate TP can provide managers, auditors access

Access to state handled similarly
Introduction to Computer Security 2004 Matt Bishop Slide #1-114 November 1, 2004
Comparison to Biba
Biba
No notion of certification rules; trusted subjects ensure actions obey rules Untrusted data examined before being made trusted
Clark-Wilson
Explicit requirements that actions must meet Trusted entity must certify method to upgrade untrusted data (and not certify the data itself)
Key Points
Integrity policies deal with trust
As trust is hard to quantify, these policies are hard to evaluate completely Look for assumptions and trusted users to find possible weak points in their implementation
Biba based on multilevel integrity Clark-Wilson focuses on separation of duty and transactions
Chapter 7: Hybrid Policies

Overview Chinese Wall Model Clinical Information Systems Security Policy ORCON RBAC
Overview
Chinese Wall Model
Focuses on conflict of interest
CISS Policy
Combines integrity and confidentiality
ORCON
Combines mandatory, discretionary access controls
RBAC
Base controls on job function
Chinese Wall Model

Problem:
Tony advises American Bank about investments He is asked to advise Toyland Bank about investments
Conflict of interest to accept, because his advice for either bank would affect his advice to the other bank
Organization
Organize entities into conflict of interest classes Control subject accesses to each class Control writing to all classes to ensure information is not passed along in violation of rules Allow sanitized data to be viewed by everyone
Definitions
Objects: items of information related to a company Company dataset (CD): contains objects related to a single company
Written CD(O)
Conflict of interest class (COI): contains datasets of companies in competition

Written COI(O) Assume: each object belongs to exactly one COI class
Example
Bank COI Class Bank of America Citibank Bank of the West Gasoline Company COI Class Shell Oil Union 76 Standard Oil ARCO
November 1, 2004
Slide #1-122
Temporal Element
If Anthony reads any CD in a COI, he can never read another CD in that COI
Possible that information learned earlier may allow him to make decisions later Let PR(S) be set of objects that S has already read
November 1, 2004
Slide #1-123
CW-Simple Security Condition

s can read o iff either condition holds:
1. There is an o such that s has accessed o and CD(o) = CD(o)
Meaning s has read something in os dataset Meaning s has not read any objects in os conflict of interest class
2.
For all o O, o PR(s) COI(o) COI(o)
Ignores sanitized data (see below) Initially, PR(s) = , so initial read request granted
November 1, 2004
Sanitization
Public information may belong to a CD
As is publicly available, no conflicts of interest arise So, should not affect ability of analysts to read Typically, all sensitive data removed from such information before it is released publicly (called sanitization)
Add third condition to CW-Simple Security Condition:

3. o is a sanitized object
Introduction to Computer Security 2004 Matt Bishop Slide #1-125 November 1, 2004
Writing
Anthony, Susan work in same trading house Anthony can read Bank 1s CD, Gas CD Susan can read Bank 2s CD, Gas CD If Anthony could write to Gas CD, Susan can read it
Hence, indirectly, she can read information from Bank 1s CD, a clear conflict of interest
CW-*-Property
s can write to o iff both of the following hold:
1. The CW-simple security condition permits s to read o; and 2. For all unsanitized objects o, if s can read o, then CD(o) = CD(o)
Says that s can write to an object if all the (unsanitized) objects it can read are in the same dataset
Compare to Bell-LaPadula
Fundamentally different
CW has no security labels, B-LP does CW has notion of past accesses, B-LP does not
Bell-LaPadula can capture state at any time

Each (COI, CD) pair gets security category Two clearances, S (sanitized) and U (unsanitized)
S dom U
Subjects assigned clearance for compartments without multiple categories corresponding to CDs in same COI class
Bell-LaPadula cannot track changes over time
Susan becomes ill, Anna needs to take over
C-W history lets Anna know if she can No way for Bell-LaPadula to capture this
Access constraints change over time

Initially, subjects in C-W can read any object Bell-LaPadula constrains set of objects that a subject can access
Cant clear all subjects for all categories, because this violates CW-simple security condition
November 1, 2004 Slide #1-129
Compare to Clark-Wilson
Clark-Wilson Model covers integrity, so consider only access control aspects If subjects and processes are interchangeable, a single person could use multiple processes to violate CW-simple security condition
Would still comply with Clark-Wilson Model
If subject is a specific person and includes all processes the subject executes, then consistent with Clark-Wilson Model
Clinical Information Systems Security Policy

Intended for medical records
Conflict of interest not critical problem Patient confidentiality, authentication of records and annotators, and integrity are
Entities:
Patient: subject of medical records (or agent) Personal health information: data about patients health or treatment enabling identification of patient Clinician: health-care professional with access to personal health information while doing job
Assumptions and Principles

Assumes health information involves 1 person at a time
Not always true; OB/GYN involves father as well as mother
Principles derived from medical ethics of various societies, and from practicing clinicians
Access
Principle 1: Each medical record has an access control list naming the individuals or groups who may read and append information to the record. The system must restrict access to those identified on the access control list.
Idea is that clinicians need access, but no-one else. Auditors get access to copies, so they cannot alter records
Access
Principle 2: One of the clinicians on the access control list must have the right to add other clinicians to the access control list.
Called the responsible clinician
November 1, 2004
Slide #1-134
Access
Principle 3: The responsible clinician must notify the patient of the names on the access control list whenever the patients medical record is opened. Except for situations given in statutes, or in cases of emergency, the responsible clinician must obtain the patients consent.
Patient must consent to all treatment, and must know of violations of security
Access
Principle 4: The name of the clinician, the date, and the time of the access of a medical record must be recorded. Similar information must be kept for deletions.
This is for auditing. Dont delete information; update it (last part is for deletion of records after death, for example, or deletion of information when required by statute). Record information about all accesses.
Creation
Principle: A clinician may open a record, with the clinician and the patient on the access control list. If a record is opened as a result of a referral, the referring clinician may also be on the access control list.
Creating clinician needs access, and patient should get it. If created from a referral, referring clinician needs access to get results of referral.
Deletion
Principle: Clinical information cannot be deleted from a medical record until the appropriate time has passed.
This varies with circumstances.
November 1, 2004
Slide #1-138
Confinement
Principle: Information from one medical record may be appended to a different medical record if and only if the access control list of the second record is a subset of the access control list of the first.
This keeps information from leaking to unauthorized users. All users have to be on the access control list.
Aggregation
Principle: Measures for preventing aggregation of patient data must be effective. In particular, a patient must be notified if anyone is to be added to the access control list for the patients record and if that person has access to a large number of medical records.
Fear here is that a corrupt investigator may obtain access to a large number of records, correlate them, and discover private information about individuals which can then be used for nefarious purposes (such as blackmail)
Enforcement
Principle: Any computer system that handles medical records must have a subsystem that enforces the preceding principles. The effectiveness of this enforcement must be subject to evaluation by independent auditors.
This policy has to be enforced, and the enforcement mechanisms must be auditable (and audited)
Confinement Principle imposes lattice structure on entities in model
Similar to Bell-LaPadula
CISS focuses on objects being accessed; BLP on the subjects accessing the objects
May matter when looking for insiders in the medical environment
Compare to Clark-Wilson
CDIs are medical records TPs are functions updating records, access control lists IVPs certify:
A person identified as a clinician is a clinician; A clinician validates, or has validated, information in the medical record; When someone is to be notified of an event, such notification occurs; and When someone must give consent, the operation cannot proceed until the consent is obtained
Auditing (CR4) requirement: make all records appendonly, notify patient when access control list changed
ORCON
Problem: organization creating document wants to control its dissemination
Example: Secretary of Agriculture writes a memo for distribution to her immediate subordinates, and she must give permission for it to be disseminated further. This is originator controlled (here, the originator is a person).
November 1, 2004
Slide #1-144
Requirements
Subject s S marks object o O as ORCON on behalf of organization X. X allows o to be disclosed to subjects acting on behalf of organization Y with the following restrictions:
1. 2. o cannot be released to subjects acting on behalf of other organizations without Xs permission; and Any copies of o must have the same restrictions placed on it.
November 1, 2004
Slide #1-145
DAC Fails
Owner can set any desired permissions
This makes 2 unenforceable
November 1, 2004
Slide #1-146
MAC Fails
First problem: category explosion
Category C contains o, X, Y, and nothing else. If a subject y Y wants to read o, x X makes a copy o. Note o has category C. If y wants to give z Z a copy, z must be in Yby definition, its not. If x wants to let w W see the document, need a new category C containing o, X, W.
Second problem: abstraction

MAC classification, categories centrally controlled, and access controlled by a centralized policy ORCON controlled locally
Combine Them
The owner of an object cannot change the access controls of the object. When an object is copied, the access control restrictions of that source are copied and bound to the target of the copy.
These are MAC (owner cant control them)
The creator (originator) can alter the access control restrictions on a per-subject and per-object basis.
This is DAC (owner can control it)
RBAC
Access depends on function, not identity
Example:
Allison, bookkeeper for Math Dept, has access to financial records. She leaves. Betty hired as the new bookkeeper, so she now has access to those records
The role of bookkeeper dictates access, not the identity of the individual.
Definitions
Role r: collection of job functions
trans(r): set of authorized transactions for r
Active role of subject s: role s is currently in

actr(s)
Authorized roles of a subject s: set of roles s is authorized to assume

authr(s)
canexec(s, t) iff subject s can execute transaction t at current time

Axioms
Let S be the set of subjects and T the set of transactions. Rule of role assignment: (s S)(t T) [canexec(s, t) actr(s) ].
If s can execute a transaction, it has a role This ties transactions to roles
Rule of role authorization: (s S) [actr(s) authr(s)].

Subject must be authorized to assume an active role (otherwise, anyIntroduction subjecttocould assume any role) Slide #1-151 November 1, 2004 Computer Security
2004 Matt Bishop
Axiom
Rule of transaction authorization: (s S)(t T) [canexec(s, t) t trans(actr(s))].
If a subject s can execute a transaction, then the transaction is an authorized one for the role s has assumed
November 1, 2004
Slide #1-152
Containment of Roles
Trainer can do all transactions that trainee can do (and then some). This means role r contains role r (r > r). So:
(s S)[ r authr(s) r > r r authr(s) ]
November 1, 2004
Slide #1-153
Separation of Duty
Let r be a role, and let s be a subject such that r auth(s). Then the predicate meauth(r) (for mutually exclusive authorizations) is the set of roles that s cannot assume because of the separation of duty requirement. Separation of duty:
(r1, r2 R) [ r2 meauth(r1) [ (s S) [ r1 authr(s) r2 authr(s) ] ] ]
Key Points
Hybrid policies deal with both confidentiality and integrity
Different combinations of these
ORCON model neither MAC nor DAC

Actually, a combination
RBAC model controls access based on functionality

Chapter 8: Basic Cryptography

Classical Cryptography Public Key Cryptography Cryptographic Checksums
November 1, 2004
Slide #1-156
Overview
Classical Cryptography
Csar cipher Vignere cipher DES
Public Key Cryptography

Diffie-Hellman RSA
Cryptographic Checksums
HMAC
Cryptosystem
Quintuple (E, D, M, K, C)
M set of plaintexts K set of keys C set of ciphertexts E set of encryption functions e: M K C D set of decryption functions d: C K M
November 1, 2004
Slide #1-158
Example
Example: Csar cipher
M = { sequences of letters } K = { i | i is an integer and 0 i 25 } E = { Ek | k K and for all letters m, Ek(m) = (m + k) mod 26 } D = { Dk | k K and for all letters c, Dk(c) = (26 + c k) mod 26 } C=M
November 1, 2004
Slide #1-159
Attacks
Opponent whose goal is to break cryptosystem is the adversary
Assume adversary knows algorithm used, but not key
Three types of attacks:

ciphertext only: adversary has only ciphertext; goal is to find plaintext, possibly key known plaintext: adversary has ciphertext, corresponding plaintext; goal is to find key chosen plaintext: adversary may supply plaintexts and obtain corresponding ciphertext; goal is to find key
Basis for Attacks

Mathematical attacks
Based on analysis of underlying mathematics
Statistical attacks
Make assumptions about the distribution of letters, pairs of letters (digrams), triplets of letters (trigrams), etc.
Called models of the language
Examine ciphertext, correlate properties with the assumptions.

Classical Cryptography
Sender, receiver share common key
Keys may be the same, or trivial to derive from one another Sometimes called symmetric cryptography
Two basic types

Transposition ciphers Substitution ciphers Combinations are called product ciphers
Transposition Cipher
Rearrange letters in plaintext to produce ciphertext Example (Rail-Fence Cipher)
Plaintext is HELLO W O RLD Rearrange as HL O OL EL W R D Ciphertext is HLO O L ELW R D
Attacking the Cipher

Anagramming
If 1-gram frequencies match English frequencies, but other n-gram frequencies do not, probably transposition Rearrange letters to form n-grams with highest frequencies
November 1, 2004
Slide #1-164
Example
Ciphertext: HLO OLEL W R D Frequencies of 2-grams beginning with H
HE 0.0305 HO 0.0043 HL, HW, HR, HD < 0.0010
Frequencies of 2-grams ending in H

WH 0.0026 EH, LH, OH, RH, DH 0.0002
Implies E follows H
Example
Arrange so the H and E are adjacent
HE LL OW OR LD
Read off across, then down, to get original plaintext

Substitution Ciphers
Change characters in plaintext to produce ciphertext Example (Csar cipher)
Plaintext is HELLO W O RLD Change each letter to the third letter following it (X goes to A, Y to B, Z to C)
Key is 3, usually written as letter D
Ciphertext is KH O O R ZRUO G

Exhaustive search
If the key space is small enough, try all possible keys until you find the right one Csar cipher has 26 possible keys
Statistical analysis
Compare to 1-gram model of English
November 1, 2004
Slide #1-168
Statistical Attack
Compute frequency of each letter in ciphertext:
G 0.1 R 0.2 H 0.1 U 0.1 K 0.1 Z 0.1 O 0.3
Apply 1-gram model of English

Frequency of characters (1-grams) in English is on next slide
Character Frequencies
a b c d e f g 0.080 0.015 0.030 0.040 0.130 0.020 0.015
h i j k l m
0.060 0.065 0.005 0.005 0.035 0.030
n o p q r s
0.070 0.080 0.020 0.002 0.065 0.060
t u v x y z
0.090 0.030 0.010 0.005 0.020 0.002

Slide #1-170
w 0.015
November 1, 2004
Statistical Analysis
f(c) frequency of character c in ciphertext (i) correlation of frequency of letters in ciphertext with corresponding letters in English, assuming key is i
(i) = 0 c 25 f(c)p(c i) so here, (i) = 0.1p(6 i) + 0.1p(7 i) + 0.1p(10 i) + 0.3p(14 i) + 0.2p(17 i) + 0.1p(20 i) + 0.1p(25 i)
p(x) is frequency of character x in English
Correlation: (i) for 0 i 25

i 0 1 2 3 4 5 6 (i) 0.0482 0.0364 0.0410 0.0575 0.0252 0.0190 0.0660 i 7 8 9 10 11 12 (i) 0.0442 0.0202 0.0267 0.0635 0.0262 0.0325 i 13 14 15 16 17 18 (i) 0.0520 0.0535 0.0226 0.0322 0.0392 0.0299 i 19 20 21 22 23 24 25 (i) 0.0315 0.0302 0.0517 0.0380 0.0370 0.0316 0.0430
Slide #1-172
November 1, 2004
The Result
Most probable keys, based on :
i = 6, (i) = 0.0660
plaintext EBI I L TLOLA
i = 10, (i) = 0.0635

plaintext AXEEH PHKE W
i = 3, (i) = 0.0575
plaintext HELLO W O RLD
i = 14, (i) = 0.0535

plaintext WTAAD LD G AS
Only English phrase is for i = 3

Thats the key (3 or D)
Csars Problem
Key is too short
Can be found by exhaustive search Statistical frequencies not concealed well
They look too much like regular English letters
So make it longer
Multiple letters in key Idea is to smooth the statistical frequencies to make cryptanalysis harder
Vignere Cipher
Like Csar cipher, but use a phrase Example
Message THE BOY HAS THE BALL Key VIG Encipher using Csar cipher for each letter: key V I G VIG VIG VIG VIG V p la in THEB O YHASTHEBALL c ipher OPKW W ECIY OPK WIR G
Relevant Parts of Tableau

A B E H L O S T Y G G H L N R U Y Z E I I J M P T W A B H V V W Z C G J N O T
Tableau shown has relevant rows, columns only Example encipherments:
key V, letter T: follow V column down to T row (giving O) Key I, letter H: follow I column down to H row (giving P)
November 1, 2004
Slide #1-176
Useful Terms
period: length of key
In earlier example, period is 3
tableau: table used to encipher and decipher

Vignere cipher has key letters on top, plaintext letters on the left
polyalphabetic: the key has several different letters

Csar cipher is monoalphabetic

Approach
Establish period; call it n Break message into n parts, each part being enciphered using the same key letter Solve each part
You can leverage one part from another
We will show each step

The Target Cipher

We want to break this cipher:
AD Q YS MIUSB O XKKT MIBHK I ZO O O E Q O O G IFBA G KAU MF VVTAA C IDT W M O CIO E Q O O G BM BFV ZG G W P CIEK Q HS N E W VECNE DLAAV R W KXS VNSVP H CEUT Q OIOF M E GJS WTPC H AJM O C HIUIX
Establish Period
Kaskski: repetitions in the ciphertext occur when characters of the key appear over the same characters in the plaintext Example:
key V IGVIGVIGVIG VIGV p la in THEB OYHASTHEBALL c ipher OPK W W ECIYO PKWIRG Note the key and plaintext line up over the repetitions (underlined). As distance between repetitions is 9, the period is a factor of 9 (that is, 1, 3, or 9)
Repetitions in Example
Letters MI OO OEQ O O G FV AA MOC QO PC NE SV CH
November 1, 2004
Start 5 22 24 39 43 50 56 69 77 94 118
End 15 27 54 63 87 122 105 117 83 97 124
Distance
Factors
10 2, 5 5 5 30 2, 3, 5 24 2, 2, 2, 3 44 2, 2, 11 72 2, 2, 2, 3, 3 49 7, 7 48 2, 2, 2, 2, 3 6 2, 3 3 3 6 2, 3
Slide #1-181
Estimate of Period
OEQOOG is probably not a coincidence
Its too long for that Period may be 1, 2, 3, 5, 6, 10, 15, or 30
Most others (7/10) have 2 in their factors Almost as many (6/10) have 3 in their factors Begin with period of 2 3 = 6
Check on Period
Index of coincidence is probability that two randomly chosen letters from ciphertext will be the same Tabulated for different periods:
1 0.066 3 0.047 2 0.052 4 0.045 Large 0.038
November 1, 2004
5 10
0.044 0.041
Slide #1-183
Compute IC
IC = [n (n 1)]1 0i25 [Fi (Fi 1)]
where n is length of ciphertext and Fi the number of times character i occurs in ciphertext
Here, IC = 0.043
Indicates a key of slightly more than 5 A statistical measure, so it can be in error, but it agrees with the previous estimate (which was 6)
Splitting Into Alphabets

alphabet 1: AIKH OIATTO B G EEER N E OSAI alphabet 2: DUKKEFUAW E M G K W D W SUFW J U alphabet 3: QSTIQB M A M Q B W Q VLKVTM T MI alphabet 4: YBM Z O AFC O OFPHEAXP Q EP O X alphabet 5: S O IOOG VIC O V CSVASHO G C C alphabet 6: MXB O G KVDIGZINNVVCIJH H ICs (#1, 0.069; #2, 0.078; #3, 0.078; #4, 0.056; #5, 0.124; #6, 0.043) indicate all alphabets have period 1, except #4 and #6; assume statistics off
Frequency Examination
ABCDEFG HIJKLM N O P Q R S TUVW X YZ 1 31004011301001300112000000 2 10022210013010000010404000 3 12000000201140004013021000 4 21102201000010431000000211 5 10500021200000500030020000 6 01110022311012100000030101 Letter frequencies are (H high, M medium, L low): H M M M H M M H H M M M M H H MLH H H MLLLLL
Begin Decryption
First matches characteristics of unshifted alphabet Third matches if I shifted to A Sixth matches if V shifted to A Substitute into ciphertext (bold are substitutions) A DIYS RIUK B O C K K L MIGH K A Z O TO EIOO L I FT AG PA U E F VAT A S CIIT W E O C N O EIOO L B M T FV E G G O P CNE K I HS SE W N E C SE D D AA A R W C XS A N S N P H HE U L Q O N O F EEG O S W L PC M AJ E O C MI U A X
November 1, 2004
Look For Clues

AJ E in last line suggests are, meaning second alphabet maps A into S: ALIYS RICK B O C KSL MIGHS A Z O TO MI OO L I NT AG PA CE F VATIS CIITE E O C N O MI OO L B UT FV E G O O P CNESI HS SEE N E C SE LD AA A RE C XS A N A N P H HECL Q O N O N EE G O S EL PC M A RE O C MICA X
Next Alphabet
MICAX in last line suggests mical (a common ending for an adjective), meaning fourth alphabet maps O into A: ALIM S RICKP O C KSL A IGHS A N O T O MIC O L I NT O G PA CET VATIS QIITE EC C N O MIC O L B UTT V E G O O D CNESI VSSEE NS C SE LD O A A RE C L S A N A N D H HECL E O N O N ES G O S ELD C M A REC C MICAL
Got It!
QI means that U maps into I, as Q is always followed by U:
ALIM E RICKP A C K SL A U G H S ANAT O MICAL I NT O S PA CET HATIS QUITE EC O N O MICAL B UTTH E G O O D ONESI VESEE NS O SE LD O M A RE C LE A N A N D THECL EA N O N ESSO S ELDO M A REC O MICAL
One-Time Pad
A Vigenre cipher with a random key at least as long as the message
Provably unbreakable Why? Look at ciphertext DXQ R . Equally likely to correspond to plaintext D OIT (key AJIY) and to plaintext DO NT (key AJDY ) and any other 4 letters Warning: keys must be random, or you can attack the cipher by trying to regenerate the key
Approximations, such as using pseudorandom number generators to generate keys, are not random
Overview of the DES

A block cipher:
encrypts blocks of 64 bits using a 64 bit key outputs 64 bits of ciphertext
A product cipher
basic unit is the bit performs both substitution and transposition (permutation) on the bits
Cipher consists of 16 rounds (iterations) each with a round key generated from the user-supplied key
Generation of Round Keys

key PC-1
Round keys are 48 bits each

D0
C0
LSH
LSH PC-2 K1
C1 LSH
D1 LSH
PC-2
K16
Slide #1-193
November 1, 2004
Encipherment
input IP
L0
R0 f R1 = L0 f(R0 , K1) K1
L1 = R 0
R16 = L 15 - f (R15, K16)
L16 = R15
IP1
output
November 1, 2004
Slide #1-194
The f Function
R i1 (32 bits) Ki (48 bits) E
R i1 (48 bits) S1 S2 S3 S4
S5 S6
6 bits into each S7 S8
4 bits out of each P 32 bits

Controversy
Considered too weak
Diffie, Hellman said in a few years technology would allow DES to be broken in days
Design using 1999 technology published
Design decisions not public

S-boxes may have backdoors
November 1, 2004
Slide #1-196
Undesirable Properties
4 weak keys
They are their own inverses
12 semi-weak keys
Each has another semi-weak key as inverse
Complementation property
DESk(m) = c DESk(m) = c
S-boxes exhibit irregular properties

Distribution of odd, even numbers non-random Outputs of fourth box depends on input to third box
Differential Cryptanalysis
A chosen ciphertext attack
Requires 247 plaintext, ciphertext pairs
Revealed several properties

Small changes in S-boxes reduce the number of pairs needed Making every bit of the round keys independent does not impede attack
Linear cryptanalysis improves result

Requires 243 plaintext, ciphertext pairs
DES Modes
Electronic Code Book Mode (ECB)
Encipher each block independently
Cipher Block Chaining Mode (CBC)

Xor each block with previous ciphertext block Requires an initialization vector for the first one
Encrypt-Decrypt-Encrypt Mode (2 keys: k, k) Encrypt-Encrypt-Encrypt Mode (3 keys: k, k, k)

c = DESk(DESk (DESk(m)))
c = DESk(DESk1(DESk(m)))
CBC Mode Encryption

init. vector
m1 m2
DES
DES
c1
c2
sent
sent
November 1, 2004
Slide #1-200
CBC Mode Decryption

init. vector
c1 c2
DES
DES
m1
m2
November 1, 2004
Slide #1-201
Self-Healing Property
Initial message
3231343336353837 3231343336353837 3231343336353837 3231343336353837
Received as (underlined 4c should be 4b)

ef7c4cb2b4ce6f3b f 6266e3a97af0e2c 746ab9a6308f4256 33e60b451b09603d
Which decrypts to
efca61e19f4836f1 3231333336353837 3231343336353837 3231343336353837
Incorrect bytes underlined Plaintext heals after 2 blocks

Current Status of DES

Design for computer system, associated software that could break any DES-enciphered message in a few days published in 1998 Several challenges to break DES messages solved using distributed computing NIST selected Rijndael as Advanced Encryption Standard, successor to DES
Designed to withstand attacks that were successful on DES
Public Key Cryptography

Two keys
Private key known only to individual Public key available to anyone
Public key, private key inverses
Idea
Confidentiality: encipher using public key, decipher using private key Integrity/authentication: encipher using private key, decipher using public one
Requirements
1. It must be computationally easy to encipher or decipher a message given the appropriate key 2. It must be computationally infeasible to derive the private key from the public key 3. It must be computationally infeasible to determine the private key from a chosen plaintext attack
RSA
Exponentiation cipher Relies on the difficulty of determining the number of numbers relatively prime to a large integer n
November 1, 2004
Slide #1-206
Background
Totient function (n)
Number of positive integers less than n and relatively prime to n
Relatively prime means with no factors in common with n
Example: (10) = 4
1, 3, 7, 9 are relatively prime to 10
Example: (21) = 12
1, 2, 4, 5, 8, 10, 11, 13, 16, 17, 19, 20 are relatively prime to 21
Algorithm
Choose two large prime numbers p, q
Let n = pq; then (n) = (p1)(q1) Choose e < n such that e is relatively prime to (n). Compute d such that ed mod (n) = 1
Public key: (e, n); private key: d Encipher: c = me mod n Decipher: m = cd mod n
Example: Confidentiality
Take p = 7, q = 11, so n = 77 and (n) = 60 Alice chooses e = 17, making d = 53 Bob wants to send Alice secret message HELLO (07 04 11 11 14)
0717 mod 77 = 28 0417 mod 77 = 16 1117 mod 77 = 44 1117 mod 77 = 44 1417 mod 77 = 42
Bob sends 28 16 44 44 42
November 1, 2004
Example
Alice receives 28 16 44 44 42 Alice uses private key, d = 53, to decrypt message:
Alice translates message to letters to read HELLO

No one else could read it, as only Alice knows her private key and that is needed for decryption
Example: Integrity/Authentication
Take p = 7, q = 11, so n = 77 and (n) = 60 Alice chooses e = 17, making d = 53 Alice wants to send Bob message HELLO (07 04 11 11 14) so Bob knows it is what Alice sent (no changes in transit, and authenticated)
Alice sends 35 09 44 44 49
Example
Bob receives 35 09 44 44 49 Bob uses Alices public key, e = 17, n = 77, to decrypt message:
Bob translates message to letters to read HELLO

Alice sent it as only she knows her private key, so no one else could have enciphered it If (enciphered) messages blocks (letters) altered in transit, would not decrypt properly
November 1, 2004
Slide #1-212
Example: Both
Alice wants to send Bob message HELLO both enciphered and authenticated (integrity-checked)
Alices keys: public (17, 77); private: 53 Bobs keys: public: (37, 77); private: 13
Alice enciphers HELLO (07 04 11 11 14):

(0753 mod 77)37 mod 77 = 07 (0453 mod 77)37 mod 77 = 37 (1153 mod 77)37 mod 77 = 44 (1153 mod 77)37 mod 77 = 44 (1453 mod 77)37 mod 77 = 14
Alice sends 07 37 44 44 14
Security Services
Confidentiality
Only the owner of the private key knows it, so text enciphered with public key cannot be read by anyone except the owner of the private key
Authentication
Only the owner of the private key knows it, so text enciphered with private key must have been generated by the owner
More Security Services

Integrity
Enciphered letters cannot be changed undetectably without knowing private key
Non-Repudiation
Message enciphered with private key came from someone who knew it
November 1, 2004
Slide #1-215
Warnings
Encipher message in blocks considerably larger than the examples here
If 1 character per block, RSA can be broken using statistical attacks (just like classical cryptosystems) Attacker cannot alter letters, but can rearrange them and alter message meaning
Example: reverse enciphered message of text ON to get NO
Cryptographic Checksums
Mathematical function to generate a set of k bits from a set of n bits (where k n).
k is smaller then n except in unusual circumstances
Example: ASCII parity bit

ASCII has 7 bits; 8th bit is parity Even parity: even number of 1 bits Odd parity: odd number of 1 bits
Example Use
Bob receives 10111101 as bits.
Sender is using even parity; 6 1 bits, so character was received correctly
Note: could be garbled, but 2 bits would need to have been changed to preserve parity
Sender is using odd parity; even number of 1 bits, so character was not received correctly
November 1, 2004
Slide #1-218
Definition
Cryptographic checksum h: AB:
1. 2. 3. For any x A, h(x) is easy to compute For any y B, it is computationally infeasible to find x A such that h(x) = y It is computationally infeasible to find two inputs x, x A such that x x and h(x) = h(x)
Alternate form (stronger): Given any x A, it is computationally infeasible to find a different x A such that h(x) = h(x).
November 1, 2004
Slide #1-219
Collisions
If x x and h(x) = h(x), x and x are a collision
Pigeonhole principle: if there are n containers for n+1 objects, then at least one container will have 2 objects in it. Application: if there are 32 files and 8 possible cryptographic checksum values, at least one value corresponds to at least 4 files
November 1, 2004
Slide #1-220
Keys
Keyed cryptographic checksum: requires cryptographic key
DES in chaining mode: encipher message, use last n bits. Requires a key to encipher, so it is a keyed cryptographic checksum.
Keyless cryptographic checksum: requires no cryptographic key

MD5 and SHA-1 are best known; others include MD4, HAVAL, and Snefru
HMAC
Make keyed cryptographic checksums from keyless cryptographic checksums h keyless cryptographic checksum function that takes data in blocks of b bytes and outputs blocks of l bytes. k is cryptographic key of length b bytes
If short, pad with 0 bytes; if long, hash to length b
ipad is 00110110 repeated b times opad is 01011100 repeated b times HMAC-h(k, m) = h(k opad || h(k ipad || m))
exclusive or, || concatenation
Key Points
Two main types of cryptosystems: classical and public key Classical cryptosystems encipher and decipher using the same key
Or one key is easily derived from the other
Public key cryptosystems encipher and decipher using different keys

Computationally infeasible to derive one from the other
Cryptographic checksums provide a check on integrity

Chapter 9: Key Management

Session and Interchange Keys Key Exchange Cryptographic Key Infrastructure Storing and Revoking Keys Digital Signatures
November 1, 2004
Slide #1-224
Overview
Key exchange
Session vs. interchange keys Classical, public key methods
Cryptographic key infrastructure

Certificates
Key storage
Key revocation
Digital signatures
Notation
X Y : { Z || W } kX,Y
X sends Y the message produced by concatenating Z and W enciphered by key kX,Y, which is shared by users X and Y
A T : { Z } kA || { W } kA,T
A sends T a message consisting of the concatenation of Z enciphered using kA, As key, and W enciphered using kA,T, the key shared by A and T
r1, r2 nonces (nonrepeating random numbers)

Session, Interchange Keys

Alice wants to send a message m to Bob
Assume public key encryption Alice generates a random cryptographic key ks and uses it to encipher m
To be used for this message only Called a session key
She enciphers ks with Bob;s public key kB
kB enciphers all session keys Alice uses to communicate with Bob Called an interchange key
Alice sends { m } ks { ks } kB
Benefits
Limits amount of traffic enciphered with single key
Standard practice, to decrease the amount of traffic an attacker can obtain
Prevents some attacks

Example: Alice will send Bob message that is either BUY or SELL. Eve computes possible ciphertexts { BUY } kB and { SELL } kB. Eve intercepts enciphered message, compares, and gets plaintext at once
Key Exchange Algorithms

Goal: Alice, Bob get shared key
Key cannot be sent in clear
Attacker can listen in Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper
Alice, Bob may trust third party All cryptosystems, protocols publicly known
Only secret data is the keys, ancillary information known only to Alice and Bob needed to derive keys Anything transmitted is assumed known to attacker
Classical Key Exchange

Bootstrap problem: how do Alice, Bob begin?
Alice cant send it to Bob in the clear!
Assume trusted third party, Cathy

Alice and Cathy share secret key kA Bob and Cathy share secret key kB
Use this to exchange shared key ks

Simple Protocol
Alice { request for session key to Bob } kA Cathy
Alice
{ ks } kA || { ks } kB
Cathy
Alice
November 1, 2004
{ ks } kB
Bob
Slide #1-231
Problems
How does Bob know he is talking to Alice?
Replay attack: Eve records message from Alice to Bob, later replays it; Bob may think hes talking to Alice, but he isnt Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key
Protocols must provide authentication and defense against replay

Needham-Schroeder
Alice Alice Alice Alice Alice
November 1, 2004
Alice || Bob || r1 { Alice || Bob || r1 || ks || { Alice || ks } kB } kA { Alice || ks } kB { r2 } ks { r2 1 } ks

Cathy Cathy Bob Bob Bob

Slide #1-233
Argument: Alice talking to Bob

Second message
Enciphered using key only she, Cathy knows
So Cathy enciphered it
Response to first message

As r1 in it matches r1 in first message
Third message
Alice knows only Bob can read it
As only Bob can derive session key from message
Any messages enciphered with that key are from Bob

Argument: Bob talking to Alice

Third message
Enciphered using key only he, Cathy know
So Cathy enciphered it
Names Alice, session key

Cathy provided session key, says Alice is other party
Fourth message
Uses session key to determine if it is replay from Eve
If not, Alice will respond correctly in fifth message If so, Eve cant decipher r2 and so cant respond, or responds incorrectly
Denning-Sacco Modification
Assumption: all keys are secret Question: suppose Eve can obtain session key. How does that affect protocol?
In what follows, Eve knows ks { Alice || ks } kB Eve Eve Eve
November 1, 2004
Bob Bob Bob

Slide #1-236
{ r2 } ks { r2 1 } ks
Solution
In protocol above, Eve impersonates Alice Problem: replay in third step
First in previous slide
Solution: use time stamp T to detect replay Weakness: if clocks not synchronized, may either reject valid messages or accept replays
Parties with either slow or fast clocks vulnerable to replay Resetting clock does not eliminate vulnerability
Needham-Schroeder with Denning-Sacco Modification

Alice Alice Alice Alice Alice
November 1, 2004
Alice || Bob || r1 { Alice || Bob || r1 || ks || { Alice || T || ks } kB } kA { Alice || T || ks } kB { r2 } ks { r2 1 } ks

Cathy Cathy Bob Bob Bob

Slide #1-238
Otway-Rees Protocol
Corrects problem
That is, Eve replaying the third message in the protocol
Does not use timestamps

Not vulnerable to the problems that DenningSacco modification has
Uses integer n to associate all messages with particular exchange

The Protocol
Alice n || Alice || Bob || { r1 || n || Alice || Bob } kA Bob Bob
n || Alice || Bob || { r1 || n || Alice || Bob } kA || Cathy { r2 || n || Alice || Bob } kB Cathy n || { r1 || ks } kA || { r2 || ks } kB n || { r1 || ks } kA
Bob
Alice
November 1, 2004
Bob
Slide #1-240
Argument: Alice talking to Bob

Fourth message
If n matches first message, Alice knows it is part of this protocol exchange Cathy generated ks because only she, Alice know kA Enciphered part belongs to exchange as r1 matches r1 in encrypted part of first message
November 1, 2004
Slide #1-241
Argument: Bob talking to Alice

Third message
If n matches second message, Bob knows it is part of this protocol exchange Cathy generated ks because only she, Bob know kB Enciphered part belongs to exchange as r2 matches r2 in encrypted part of second message
November 1, 2004
Slide #1-242
Replay Attack
Eve acquires old ks, message in third step
n || { r1 || ks } kA || { r2 || ks } kB
Eve forwards appropriate part to Alice

Alice has no ongoing key exchange with Bob: n matches nothing, so is rejected Alice has ongoing key exchange with Bob: n does not match, so is again rejected
If replay is for the current key exchange, and Eve sent the relevant part before Bob did, Eve could simply listen to traffic; no replay involved
Kerberos
Authentication system
Based on Needham-Schroeder with Denning-Sacco modification Central server plays role of trusted third party (Cathy)
Ticket
Issuer vouches for identity of requester of service
Authenticator
Identifies sender
Idea
User u authenticates to Kerberos server
Obtains ticket Tu,TGS for ticket granting service (TGS)
User u wants to use service s:

User sends authenticator Au, ticket Tu,TGS to TGS asking for ticket for service TGS sends ticket Tu,s to user User sends Au, Tu,s to server as request to use s
Details follow
Ticket
Credential saying issuer has identified ticket requester Example ticket issued to user u for service s
Tu,s = s || { u || us address || valid time || ku,s } ks where: ku,s is session key for user and service Valid time is interval for which ticket valid us address may be IP address or something else
Note: more fields, but not relevant here
Authenticator
Credential containing identity of sender of ticket
Used to confirm sender is entity to which ticket was issued
Example: authenticator user u generates for service s

Au,s = { u || generation time || kt } ku,s where: kt is alternate session key Generation time is when authenticator generated
Note: more fields, not relevant here
Protocol
user Cathy user user user user
November 1, 2004
user || TGS { ku,TGS } ku || Tu,TGS service || Au,TGS || Tu,TGS user || { ku,s } ku,TGS || Tu,s Au,s || Tu,s { t + 1 } ku,s
Cathy user TGS TGS service service

Slide #1-248
Analysis
First two steps get user ticket to use TGS
User u can obtain session key only if u knows key shared with Cathy
Next four steps show how u gets and uses ticket for service s
Service s validates request by checking sender (using Au,s) is same as entity ticket issued to Step 6 optional; used when u requests confirmation
Problems
Relies on synchronized clocks
If not synchronized and old tickets, authenticators not cached, replay is possible
Tickets have some fixed fields

Dictionary attacks possible Kerberos 4 session keys weak (had much less than 56 bits of randomness); researchers at Purdue found them from tickets in minutes
Public Key Key Exchange

Here interchange keys known
eA, eB Alice and Bobs public keys known to all dA, dB Alice and Bobs private keys known only to owner
Simple protocol
ks is desired session key { ks } eB
Alice
November 1, 2004
Bob
Slide #1-251
Problem and Solution

Vulnerable to forgery or replay
Because eB known to anyone, Bob has no assurance that Alice sent message
Simple fix uses Alices private key

ks is desired session key
Alice
November 1, 2004
{ { ks } dA } eB
Bob
Slide #1-252
Notes
Can include message enciphered with ks Assumes Bob has Alices public key, and vice versa
If not, each must get it from public server If keys not bound to identity of owner, attacker Eve can launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys)
Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI)
November 1, 2004
Slide #1-253
Man-in-the-Middle Attack
Alice send Bobs public key Eve Eve Alice Alice eE { ks } eE Eve Eve intercepts message Eve
November 1, 2004
Eve intercepts request send Bobs public key eB
Cathy Cathy Cathy
Bob Bob
{ ks } eB
Slide #1-254
Cryptographic Key Infrastructure

Goal: bind identity to key Classical: not possible as all keys are shared
Use protocols to agree on a shared key (see earlier)
Public key: bind identity to public key

Crucial as people will use key to communicate with principal whose identity is bound to key Erroneous binding means no secrecy between principals Assume principal identified by an acceptable name
Certificates
Create token (message) containing
Identity of principal (here, Alice) Corresponding public key Timestamp (when issued) Other information (perhaps identity of signer)
signed by trusted authority (here, Cathy) CA = { eA || Alice || T } dC

Use
Bob gets Alices certificate
If he knows Cathys public key, he can decipher the certificate
When was certificate issued? Is the principal Alice?
Now Bob has Alices public key
Problem: Bob needs Cathys public key to validate certificate

Problem pushed up a level Two approaches: Merkles tree, signature chains
Certificate Signature Chains

Create certificate
Generate hash of certificate Encipher hash with issuers private key
Validate
Obtain issuers public key Decipher enciphered hash Recompute hash from certificate and compare
Problem: getting issuers public key

X.509 Chains
Some certificate components in X.509v3:
Version Serial number Signature algorithm identifier: hash algorithm Issuers name; uniquely identifies issuer Interval of validity Subjects name; uniquely identifies subject Subjects public key Signature: enciphered hash
November 1, 2004
X.509 Certificate Validation

Obtain issuers public key
The one for the particular signature algorithm
Decipher signature
Gives hash of certificate
Recompute hash from certificate and compare

If they differ, theres a problem
Check interval of validity

This confirms that certificate is current
Issuers
Certification Authority (CA): entity that issues certificates
Multiple issuers pose validation problem Alices CA is Cathy; Bobs CA is Don; how can Alice validate Bobs certificate? Have Cathy and Don cross-certify
Each issues certificate for the other
November 1, 2004
Slide #1-261
Validation and Cross-Certifying

Certificates:
Cathy<<Alice>> Dan<<Bob> Cathy<<Dan>> Dan<<Cathy>>
Alice validates Bobs certificate

Alice obtains Cathy<<Dan>> Alice uses (known) public key of Cathy to validate Cathy<<Dan>> Alice uses Cathy<<Dan>> to validate Dan<<Bob>>
PGP Chains
OpenPGP certificates structured into packets
One public key packet Zero or more signature packets
Public key packet:

Version (3 or 4; 3 compatible with all versions of PGP, 4 not compatible with older versions of PGP) Creation time Validity period (not present in version 3) Public key algorithm, associated parameters Public key
OpenPGP Signature Packet

Version 3 signature packet
Version (3) Signature type (level of trust) Creation time (when next fields hashed) Signers key identifier (identifies key to encipher hash) Public key algorithm (used to encipher hash) Hash algorithm Part of signed hash (used for quick check) Signature (enciphered hash)
Version 4 packet more complex

November 1, 2004
Signing
Single certificate may have multiple signatures Notion of trust embedded in each signature
Range from untrusted to ultimate trust Signer defines meaning of trust level (no standards!)
All version 4 keys signed by subject

Called self-signing
November 1, 2004
Slide #1-265
Validating Certificates
Alice needs to validate Bobs OpenPGP cert
Does not know Fred, Giselle, or Ellen
Arrows show signatures Self signatures not shown Jack Henry Irene Ellen Giselle Fred Bob
Slide #1-266
Alice gets Giselles cert

Knows Henry slightly, but his signature is at casual level of trust
Alice gets Ellens cert

Knows Jack, so uses his cert to validate Ellens, then hers to validate Bobs
November 1, 2004
Storing Keys
Multi-user or networked systems: attackers may defeat access control mechanisms
Encipher file containing key
Attacker can monitor keystrokes to decipher files Key will be resident in memory that attacker may be able to read
Use physical devices like smart card

Key never enters system Card can be stolen, so have 2 devices combine bits to make single key
Key Revocation
Certificates invalidated before expiration
Usually due to compromised key May be due to change in circumstance (e.g., someone leaving company)
Problems
Entity revoking certificate authorized to do so Revocation information circulates to everyone fast enough
Network delays, infrastructure problems may delay information
CRLs
Certificate revocation list lists certificates that are revoked X.509: only certificate issuer can revoke certificate
Added to CRL
PGP: signers can revoke signatures; owners can revoke certificates, or allow others to do so
Revocation message placed in PGP packet and signed Flag marks it as revocation message
Digital Signature
Construct that authenticated origin, contents of message in a manner provable to a disinterested third party (judge) Sender cannot deny having sent message (service is nonrepudiation)
Limited to technical proofs
Inability to deny ones cryptographic key was used to sign
One could claim the cryptographic key was stolen or compromised

Legal proofs, etc., probably required; not dealt with here
Common Error
Classical: Alice, Bob share key k
Alice sends m || { m } k to Bob
This is a digital signature WRONG This is not a digital signature

Why? Third party cannot determine whether Alice or Bob generated message
Classical Digital Signatures

Require trusted third party
Alice, Bob each share keys with trusted party Cathy
To resolve dispute, judge gets { m } kAlice, { m } kBob, and has Cathy decipher them; if messages matched, contract was signed Alice Cathy Cathy
November 1, 2004
{ m }kAlice { m }kAlice { m }kBob

Bob Bob Bob

Slide #1-272
Public Key Digital Signatures

Alices keys are dAlice, eAlice Alice sends Bob
m || { m } dAlice
In case of dispute, judge computes

{ { m } dAlice } eAlice
and if it is m, Alice signed message

Shes the only one who knows dAlice!
RSA Digital Signatures

Use private key to encipher message
Protocol for use is critical
Key points:
Never sign random documents, and when signing, always sign hash and never document
Mathematical properties can be turned against signer
Sign message first, then encipher

Changing public keys causes forgery
Attack #1
Example: Alice, Bob communicating
nA = 95, eA = 59, dA = 11 nB = 77, eB = 53, dB = 17
26 contracts, numbered 00 to 25
Alice has Bob sign 05 and 17: Alice computes 0517 mod 77 = 08; corresponding signature is 0319 mod 77 = 57; claims Bob signed 08 Judge computes ceB mod nB = 5753 mod 77 = 08
Signature validated; Bob is toast
c = mdB mod nB = 0517 mod 77 = 3 c = mdB mod nB = 1717 mod 77 = 19
Attack #2: Bobs Revenge

Bob, Alice agree to sign contract 06 Alice enciphers, then signs:
(meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63
Bob now changes his public key

Computes r such that 13r mod 77 = 6; say, r = 59 Computes reB mod (nB) = 5953 mod 60 = 7 Replace public key eB with 7, private key dB = 43
Bob claims contract was 13. Judge computes:

(6359 mod 95)43 mod 77 = 13 Verified; now Alice is toast
Key Points
Key management critical to effective use of cryptosystems
Different levels of keys (session vs. interchange)
Keys need infrastructure to identify holders, allow revoking

Key escrowing complicates infrastructure
Digital signatures provide integrity of origin and content

Much easier with public key cryptosystems than with classical cryptosystems
Chapter 10: Cipher Techniques

Some Problems Types of Ciphers Networks Examples
November 1, 2004
Slide #1-278
Overview
Problems
What can go wrong if you naively use ciphers
Cipher types
Stream or block ciphers?
Networks
Link vs end-to-end use
Examples
Privacy-Enhanced Electronic Mail (PEM) Security at the Network Layer (IPsec)
Problems
Using cipher requires knowledge of environment, and threats in the environment, in which cipher will be used
Is the set of possible messages small? Do the messages exhibit regularities that remain after encipherment? Can an active wiretapper rearrange or change parts of the message?
Attack #1: Precomputation

Set of possible messages M small Public key cipher f used Idea: precompute set of possible ciphertexts f(M), build table (m, f(m)) When ciphertext f(m) appears, use table to find m Also called forward searches
Example
Cathy knows Alice will send Bob one of two messages: enciphered BUY, or enciphered SELL Using public key eBob, Cathy precomputes m1 = { BUY } eBob, m2 = { SELL } eBob Cathy sees Alice send Bob m2 Cathy knows Alice sent SELL
May Not Be Obvious

Digitized sound
Seems like far too many possible plaintexts
Initial calculations suggest 232 such plaintexts
Analysis of redundancy in human speech reduced this to about 100,000 ( 217)

This is small enough to worry about precomputation attacks
November 1, 2004
Slide #1-283
Misordered Blocks
Alice sends Bob message
nBob = 77, eBob = 17, dBob = 53 Message is LIVE (11 08 21 04) Enciphered message is 44 57 21 16
Eve intercepts it, rearranges blocks

Now enciphered message is 16 21 57 44
Bob gets enciphered message, deciphers it

He sees EVIL
Notes
Digitally signing each block wont stop this attack Two approaches:
Cryptographically hash the entire message and sign it Place sequence numbers in each block of message, so recipient can tell intended order
Then you sign each block
Statistical Regularities
If plaintext repeats, ciphertext may too Example using DES:
input (in hex):
3231 3433 3635 3837 3231 3433 3635 3837
corresponding output (in hex):

ef7c 4bb2 b4ce 6 f3b e f7c 4bb2 b4ce 6 f 3b
Fix: cascade blocks together (chaining)

More details later
November 1, 2004
Slide #1-286
What These Mean

Use of strong cryptosystems, well-chosen (or random) keys not enough to be secure Other factors:
Protocols directing use of cryptosystems Ancillary information added by protocols Implementation (not discussed here) Maintenance and operation (not discussed here)
November 1, 2004
Stream, Block Ciphers

E encipherment function
Ek(b) encipherment of message b with key k In what follows, m = b1b2 , each bi of fixed length
Block cipher
Ek(m) = Ek(b1)Ek(b2)
Stream cipher
k = k1k2 Ek(m) = Ek1(b1)Ek2(b2) If k1k2 repeats itself, cipher is periodic and the kength of its period is one cycle of k1k2
Examples
Vigenre cipher
bi = 1 character, k = k1k2 where ki = 1 character Each bi enciphered using ki mod length(k) Stream cipher
DES
bi = 64 bits, k = 56 bits Each bi enciphered separately using k Block cipher
Stream Ciphers
Often (try to) implement one-time pad by xoring each bit of key with one bit of message
Example: m = 00101 k = 10010 c = 10111
But how to generate a good key?

Synchronous Stream Ciphers

n-stage Linear Feedback Shift Register: consists of
n bit register r = r0rn1 n bit tap sequence t = t0tn1 Use:
Use rn1 as key bit Compute x = r0t0 rn1tn1 Shift r one bit to right, dropping rn1, x becomes r0
Operation
r0 rn1 bi ci r0 rn1 ri = ri1, 0<in
r0t0 + + rn1tn1
Example
4-stage LFSR; t = 1001
r ki new bit computation new r 0010 0 01001001 = 0 0001 0001 1 01000011 = 1 1000 1000 0 11000001 = 1 1100 1100 0 11100001 = 1 1110 1110 0 11101001 = 1 1111 1111 1 11101011 = 0 0111 1110 0 11101011 = 1 1011 Key sequence has period of 15 (010001111010110)
NLFSR
n-stage Non-Linear Feedback Shift Register: consists of
n bit register r = r0rn1 Use:
Use rn1 as key bit Compute x = f(r0, , rn1); f is any function Shift r one bit to right, dropping rn1, x becomes r0
Note same operation as LFSR but more general bit replacement function
Example
4-stage NLFSR; f(r0, r1, r2, r3) = (r0 & r2) | r3
r
1100 0110 0011 1001 1100 0110 0011
ki
0 0 1 1 0 0 1
new bit computation

(1 & 0) | 0 = 0 (0 & 1) | 0 = 0 (0 & 1) | 1 = 1 (1 & 0) | 1 = 1 (1 & 0) | 0 = 0 (0 & 1) | 0 = 0 (0 & 1) | 1 = 1 0110 0011 1001 1100 0110 0011 1001
new r
Key sequence has period of 4 (0011)

Eliminating Linearity
NLFSRs not common
No body of theory about how to design them to have long period
Alternate approach: output feedback mode

For E encipherment function, k key, r register:
Compute r= Ek(r); key bit is rightmost bit of r Set r to r and iterate, repeatedly enciphering register and extracting key bits, until message enciphered
Variant: use a counter that is incremented for each encipherment rather than a register
Take rightmost bit of Ek(i), where i is number of encipherment
Self-Synchronous Stream Cipher

Take key from message itself (autokey) Example: Vigenre, key drawn from plaintext
key plaintext ciphertext XTHEB O YHASTHEBA THEB OYHASTHEBA G Q ALFPNFHSLALFCT
Problem:
Statistical regularities in plaintext show in key Once you get any part of the message, you can decipher more
Another Example
Take key from ciphertext (autokey) Example: Vigenre, key drawn from ciphertext
key plaintext ciphertext X QXBC Q O VVN G N RTT THEB OYHASTHEBA G Q XBC Q O VVNG N R TT M
Problem:
Attacker gets key along with ciphertext, so deciphering is trivial
Variant
Cipher feedback mode: 1 bit of ciphertext fed into n bit register
Self-healing property: if ciphertext bit received incorrectly, it and next n bits decipher incorrectly; but after that, the ciphertext bits decipher correctly Need to know k, E to decipher ciphertext
k E
Ek(r)
mi ci
November 1, 2004
Slide #1-299
Block Ciphers
Encipher, decipher multiple bits at once Each block enciphered independently Problem: identical plaintext blocks produce identical ciphertext blocks
Example: two database records
ME M BER: H OLLY INCO M E $100,000 ME M BER: HEIDI INCOM E $100,000
Encipherment:
ABCQZ R M E GHQ M R S IB CTXUVYSS RM G R P FQ N ABCQZ R M E ORM P ABRZ CTXUVYSS RM G R P FQ N
Solutions
Insert information about blocks position into the plaintext block, then encipher Cipher block chaining:
Exclusive-or current plaintext block with previous ciphertext block:
c0 = Ek(m0 I) ci = Ek(mi ci1) for i > 0
where I is the initialization vector

Multiple Encryption
Double encipherment: c = Ek(Ek(m))
Effective key length is 2n, if k, k are length n Problem: breaking it requires 2n+1 encryptions, not 22n encryptions EDE mode: c = Ek(Dk(Ek(m))
Triple encipherment:
Problem: chosen plaintext attack takes O(2n) time using 2n ciphertexts Best attack requires O(22n) time, O(2n) memory
Triple encryption mode: c = Ek(Ek(Ek(m))
November 1, 2004
Networks and Cryptography

ISO/OSI model Conceptually, each host has peer at each layer
Peers communicate with peers at same layer
Application layer Presentation layer Session layer Transport layer Netw ork layer Data link layer Physical layer Network layer Data link layer Physical layer Application layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer
November 1, 2004
Slide #1-303
Link and End-to-End Protocols

Link Protocol
End-to-End (or E2E) Protocol
November 1, 2004
Slide #1-304
Encryption
Link encryption
Each host enciphers message so host at next hop can read it Message can be read at intermediate hosts
End-to-end encryption
Host enciphers message so host at other end of communication can read it Message cannot be read at intermediate hosts
Examples
TELNET protocol
Messages between client, server enciphered, and encipherment, decipherment occur only at these hosts End-to-end protocol
PPP Encryption Control Protocol

Host gets message, deciphers it
Figures out where to forward it Enciphers it in appropriate key and forwards it
Link protocol
Cryptographic Considerations
Link encryption
Each host shares key with neighbor Can be set on per-host or per-host-pair basis
Windsor, stripe, seaview each have own keys One key for (windsor, stripe); one for (stripe, seaview); one for (windsor, seaview)
End-to-end
Each host shares key with destination Can be set on per-host or per-host-pair basis Message cannot be read at intermediate nodes
Traffic Analysis
Link encryption
Can protect headers of packets Possible to hide source and destination
Note: may be able to deduce this from traffic flows
End-to-end encryption
Cannot hide packet headers
Intermediate nodes need to route packet
Attacker can read source, destination

Example Protocols
Privacy-Enhanced Electronic Mail (PEM)
Applications layer protocol
IP Security (IPSec)
Network layer protocol
November 1, 2004
Slide #1-309
Goals of PEM
1. Confidentiality
Only sender and recipient(s) can read message Identify the sender precisely Any changes in message are easy to detect Whenever possible
2. Origin authentication 3. Data integrity 4. Non-repudiation of origin
November 1, 2004
Message Handling System

UA UA UA User Agents
MTA
MTA
MTA
Message Transfer Agents
November 1, 2004
Slide #1-311
Design Principles
Do not change related existing protocols
Cannot alter SMTP
Do not change existing software

Need compatibility with existing software
Make use of PEM optional

Available if desired, but email still works without them Some recipients may use it, others not
Enable communication without prearrangement

Out-of-bands authentication, key exchange problematic
Basic Design: Keys

Two keys
Interchange keys tied to sender, recipients and is static (for some set of messages)
Like a public/private key pair Must be available before messages sent
Data exchange keys generated for each message

Like a session key, session being the message
November 1, 2004
Slide #1-313
Basic Design: Sending

Confidentiality
m message ks data exchange key kB Bobs interchange key { m } ks || { ks } kB
Alice
Bob
November 1, 2004
Slide #1-314
Basic Design: Integrity

Integrity and authentication:
m message h(m) hash of message m Message Integrity Check (MIC) kA Alices interchange key Alice m { h(m) } kA Bob
Non-repudiation: if kA is Alices private key, this establishes that Alices private key was used to sign the message
Basic Design: Everything

Confidentiality, integrity, authentication:
Notations as in previous slides If kA is private key, get non-repudiation too { m } ks || { h(m) } kA || { ks } kB Bob
Alice
November 1, 2004
Slide #1-316
Practical Considerations
Limits of SMTP
Only ASCII characters, limited length lines
Use encoding procedure

1. Map local char representation into canonical format
Format meets SMTP requirements
2. Compute and encipher MIC over the canonical format; encipher message if needed 3. Map each 6 bits of result into a character; insert newline after every 64th character 4. Add delimiters around this ASCII message
Problem
Recipient without PEM-compliant software cannot read it
If only integrity and authentication used, should be able to read it
Mode MIC-CLEAR allows this

Skip step 3 in encoding procedure Problem: some MTAs add blank lines, delete trailing white space, or change end of line character Result: PEM-compliant software reports integrity failure
PEM vs. PGP

Use different ciphers
PGP uses IDEA cipher PEM uses DES in CBC mode
Use different certificate models

PGP uses general web of trust PEM uses hierarchical certification structure
Handle end of line differently

PGP remaps end of line if message tagged text, but leaves them alone if message tagged binary PEM always remaps end of line
IPsec
Network layer security
Provides confidentiality, integrity, authentication of endpoints, replay detection
Protects all messages sent along a path

dest IP IP+IPsec gw2 gw1 IP src
security gateway
IPsec Transport Mode
IP header
encapsulated data body
Encapsulate IP packet data area Use IP to send IPsec-wrapped data packet Note: IP header not protected
IPsec Tunnel Mode
IP header
encapsulated data body
Encapsulate IP packet (IP header and IP data) Use IP to send IPsec-wrapped packet Note: IP header protected
IPsec Protocols
Authentication Header (AH)
Message integrity Origin authentication Anti-replay
Encapsulating Security Payload (ESP)

Confidentiality Others provided by AH
IPsec Architecture
Security Policy Database (SPD)
Says how to handle messages (discard them, add security services, forward message unchanged) SPD associated with network interface SPD determines appropriate entry from packet attributes
Including source, destination, transport protocol
Example
Goals
Discard SMTP packets from host 192.168.2.9 Forward packets from 192.168.19.7 without change
SPD entries
src 192.168.2 .9 , dest 10 .1 .2.3 to 10 .1.2 .103, por t 25 ,d iscard src 192.168.19 .7 , dest 10 .1 . 2.3 to 10 . 1.2 .103, por t 25 , bypass dest 10 .1 . 2.3 to 10 . 1.2 .103, por t 25 , app ly IPsec
Note: entries scanned in order

If no match for packet, it is discarded
IPsec Architecture
Security Association (SA)
Association between peers for security services
Identified uniquely by dest address, security protocol (AH or ESP), unique 32-bit number (security parameter index, or SPI)
Unidirectional
Can apply different services in either direction
SA uses either ESP or AH; if both required, 2 SAs needed

SA Database (SAD)
Entry describes SA; some fields for all packets:
AH algorithm identifier, keys
When SA uses AH
ESP encipherment algorithm identifier, keys

When SA uses confidentiality from ESP
ESP authentication algorithm identifier, keys

When SA uses authentication, integrity from ESP
SA lifetime (time for deletion or max byte count) IPsec mode (tunnel, transport, either)
SAD Fields
Antireplay (inbound only)
When SA uses antireplay feature
Sequence number counter (outbound only)

Generates AH or ESP sequence number
Sequence counter overflow field

Stops traffic over this SA if sequence counter overflows
Aging variables
Used to detect time-outs
IPsec Architecture
Packet arrives Look in SPD
Find appropriate entry Get dest address, security protocol, SPI
Find associated SA in SAD

Use dest address, security protocol, SPI Apply security services in SA (if any)
SA Bundles and Nesting

Sequence of SAs that IPsec applies to packets
This is a SA bundle
Nest tunnel mode SAs

This is iterated tunneling
November 1, 2004
Slide #1-330
Example: Nested Tunnels

Group in A.org needs to communicate with group in B.org Gateways of A, B use IPsec mechanisms
But the information must be secret to everyone except the two groups, even secret from other people in A.org and B.org
Inner tunnel: a SA between the hosts of the two groups Outer tunnel: the SA between the two gateways
Example: Systems
gwA.A.org
hostA.A.org
hostB.B.org
SA in tunnel mode (outer tunnel) SA in tunnel mode (inner tunnel)

November 1, 2004
gwB.B.org
Slide #1-332
Example: Packets
IP header from gwA AH header from gwA ESP header from gwA IP header from hostA AH header from hostA ESP header from hostA IP header from hostA Transport layer headers, data
Packet generated on hostA Encapsulated by hostAs IPsec mechanisms Again encapsulated by gwAs IPsec mechanisms
Above diagram shows headers, but as you go left, everything to the right would be enciphered and authenticated, etc.
AH Protocol
Parameters in AH header
Length of header SPI of SA applying protocol Sequence number (anti-replay) Integrity value check
Two steps
Check that replay is not occurring Check authentication data
Sender
Check sequence number will not cycle Increment sequence number Compute IVC of packet
Includes IP header, AH header, packet data
IP header: include all fields that will not change in transit; assume all others are 0 AH header: authentication data field set to 0 for this Packet data includes encapsulated data, higher level protocol data
Recipient
Assume AH header found Get SPI, destination address Find associated SA in SAD
If no associated SA, discard packet
If antireplay not used

Verify IVC is correct
If not, discard
Recipient, Using Antireplay

Check packet beyond low end of sliding window Check IVC of packet Check packets slot not occupied
If any of these is false, discard packet
current window
AH Miscellany
All implementations must support: HMAC_MD5 HMAC_SHA-1 May support other algorithms
November 1, 2004
Slide #1-338
ESP Protocol
Parameters in ESP header
SPI of SA applying protocol Sequence number (anti-replay) Generic payload data field Padding and length of padding
Contents depends on ESP services enabled; may be an initialization vector for a chaining cipher, for example Used also to pad packet to length required by cipher
Optional authentication data field

Sender
Add ESP header
Includes whatever padding needed
Encipher result
Do not encipher SPI, sequence numbers
If authentication desired, compute as for AH protocol except over ESP header, payload and not encapsulating IP header
Recipient
Assume ESP header found Get SPI, destination address Find associated SA in SAD
If no associated SA, discard packet
If authentication used
Do IVC, antireplay verification as for AH
Only ESP, payload are considered; not IP header Note authentication data inserted after encipherment, so no deciphering need be done
Recipient
If confidentiality used
Decipher enciphered portion of ESP heaser Process padding Decipher payload If SA is transport mode, IP header and payload treated as original IP packet If SA is tunnel mode, payload is an encapsulated IP packet and so is treated as original IP packet
ESP Miscellany
Must use at least one of confidentiality, authentication services Synchronization material must be in payload
Packets may not arrive in order, so if not, packets following a missing packet may not be decipherable
Implementations of ESP assume classical cryptosystem

Implementations of public key systems usually far slower than implementations of classical systems Not required
More ESP Miscellany

All implementations must support (encipherment algorithms):
DES in CBC mode NULL algorithm (identity; no encipherment)
All implementations must support (integrity algorithms):

HMAC_MD5 HMAC_SHA-1 NULL algorithm (no MAC computed)
Both cannot be NULL at the same time

Which to Use: PEM, IPsec

What do the security services apply to?
If applicable to one application and application layer mechanisms available, use that
PEM for electronic mail
If more generic services needed, look to lower layers

IPsec for network layer, either end-to-end or link mechanisms, for connectionless channels as well as connections
If endpoint is host, IPsec sufficient; if endpoint is user, application layer mechanism such as PEM needed
November 1, 2004
Slide #1-345
Key Points
Key management critical to effective use of cryptosystems
Different levels of keys (session vs. interchange)
Keys need infrastructure to identify holders, allow revoking

Key escrowing complicates infrastructure
Digital signatures provide integrity of origin and content

Much easier with public key cryptosystems than with classical cryptosystems
Chapter 11: Authentication

Basics Passwords Challenge-Response Biometrics Location Multiple Methods
November 1, 2004
Overview
Basics Passwords
Storage Selection Breaking them
Other methods Multiple methods

Basics
Authentication: binding of identity to subject
Identity is that of external entity (my identity, Matt, etc.) Subject is computer entity (process, etc.)
November 1, 2004
Slide #1-349
Establishing Identity
One or more of the following
What entity knows (eg. password) What entity has (eg. badge, smart card) What entity is (eg. fingerprints, retinal characteristics) Where entity is (eg. In front of a particular terminal)
November 1, 2004
Slide #1-350
Authentication System
(A, C, F, L, S)
A information that proves identity C information stored on computer and used to validate authentication information F complementation function; f : A C L functions that prove identity S functions enabling entity to create, alter information in A or C
Example
Password system, with passwords stored on line in clear text
A set of strings making up passwords C=A F singleton set of identity function { I } L single equality test function { eq } S function to set/change password
November 1, 2004
Passwords
Sequence of characters
Examples: 10 digits, a string of letters, etc. Generated randomly, by user, by computer with user input
Sequence of words
Examples: pass-phrases
Algorithms
Examples: challenge-response, one-time passwords
Storage
Store as cleartext
If password file compromised, all passwords revealed
Encipher file
Need to have decipherment, encipherment keys in memory Reduces to previous problem
Store one-way hash of password

If file read, attacker must still guess passwords or invert the hash
Example
UNIX system standard hash function
Hashes password into 11 char string using one of 4096 hash functions
As authentication system:
A = { strings of 8 chars or less } C = { 2 char hash id || 11 char hash } F = { 4096 versions of modified DES } L = { login, su, } S = { passwd, nispasswd, passwd+, }
November 1, 2004
Anatomy of Attacking
Goal: find a A such that:
For some f F, f(a) = c C c is associated with entity
Two ways to determine whether a meets these requirements:

Direct approach: as above Indirect approach: as l(a) succeeds iff f(a) = c C for some c associated with an entity, compute l(a)
November 1, 2004
Slide #1-356
Preventing Attacks
How to prevent this:
Hide one of a, f, or c
Prevents obvious attack from above Example: UNIX/Linux shadow password files
Hides cs
Block access to all l L or result of l(a)

Prevents attacker from knowing if guess succeeded Example: preventing any logins to an account from a network
Prevents knowing results of l (or accessing l)
Dictionary Attacks
Trial-and-error from a list of potential passwords
Off-line: know f and cs, and repeatedly try different guesses g A until the list is done or passwords guessed
Examples: crack, john-the-ripper
On-line: have access to functions in L and try guesses g until some l(g) succeeds
Examples: trying to log in by guessing a password
Using Time
Andersons formula: P probability of guessing a password in specified period of time G number of guesses tested in 1 time unit T number of time units N number of possible passwords (|A|) Then P TG/N
Example
Goal
Passwords drawn from a 96-char alphabet Can test 104 guesses per second Probability of a success to be 0.5 over a 365 day period What is minimum password length?
Solution
N TG/P = (365246060)104/0.5 = 6.311011 Choose s such that sj=0 96j N So s 6, meaning passwords must be at least 6 chars long
Approaches: Password Selection

Random selection
Any password from A equally likely to be selected
Pronounceable passwords User selection of passwords
November 1, 2004
Slide #1-361
Pronounceable Passwords
Generate phonemes randomly
Phoneme is unit of sound, eg. cv, vc, cvc, vcv Examples: helgoret, juttelon are; przbqxdfl, zxrptglfn are not
Problem: too few Solution: key crunching

Run long key through hash function and convert to printable sequence Use this sequence as password
November 1, 2004
Slide #1-362
User Selection
Problem: people pick easy to guess passwords
Based on account names, user names, computer names, place names Dictionary words (also reversed, odd capitalizations, control characters, elite-speak, conjugations or declensions, swear words, Torah/Bible/Koran/ words) Too short, digits only, letters only License plates, acronyms, social security numbers Personal characteristics or foibles (pet names, nicknames, job characteristics, etc.
November 1, 2004
Slide #1-363
Picking Good Passwords

LlMm*2^Ap
Names of members of 2 families
OoHeO/FSK
Second letter of each word of length 4 or more in third line of third verse of Star-Spangled Banner, followed by /, followed by authors initials
Whats good here may be bad there

DMC/MHmh bad at Dartmouth (Dartmouth Medical Center/Mary Hitchcock memorial hospital), ok here
Why are these now bad passwords? /
November 1, 2004
Slide #1-364
Proactive Password Checking

Analyze proposed password for goodness
Always invoked Can detect, reject bad passwords for an appropriate definition of bad Discriminate on per-user, per-site basis Needs to do pattern matching on words Needs to execute subprograms and use results
Spell checker, for example
Easy to set up and integrate into password selection system

Example: OPUS
Goal: check passwords against large dictionaries quickly
Run each word of dictionary through k different hash functions h1, , hk producing values less than n Set bits h1, , hk in OPUS dictionary To check new proposed word, generate bit vector and see if all corresponding bits set
If so, word is in one of the dictionaries to some degree of probability If not, it is not in the dictionaries
November 1, 2004
Slide #1-366
Example: passwd+
Provides little language to describe proactive checking
test length($p) < 6
If password under 6 characters, reject it
test infile(/usr/dict/words, $p)

If password in file /usr/dict/words, reject it
test !inprog(spell, $p, $p)

If password not in the output from program spell, given the password as input, reject it (because its a properly spelled word)
November 1, 2004
Slide #1-367
Salting
Goal: slow dictionary attacks Method: perturb hash function so that:
Parameter controls which hash function is used Parameter differs for each password So given n password hashes, and therefore n salts, need to hash guess n
November 1, 2004
Slide #1-368
Examples
Vanilla UNIX method
Use DES to encipher 0 message with password as key; iterate 25 times Perturb E table in DES in one of 4096 ways
12 bit salt flips entries 111 with entries 2536
Alternate methods
Use salt as first part of input to hash function
Guessing Through L
Cannot prevent these
Otherwise, legitimate users cannot log in
Make them slow

Backoff Disconnection Disabling
Be very careful with administrative accounts!
Jailing
Allow in, but restrict activities
November 1, 2004
Slide #1-370
Password Aging
Force users to change passwords after some time has expired
How do you force users not to re-use passwords?
Record previous passwords Block changes for a period of time
Give users time to think of good passwords

Dont force them to change before they can log in Warn them of expiration days in advance
Challenge-Response
User, system share a secret function f (in practice, f is a known function with unknown parameters, such as a cryptographic key)
request to authenticate random message r (the challenge) f(r) (the response)
user user user

November 1, 2004
system system system

Slide #1-372
Pass Algorithms
Challenge-response with the function f itself a secret
Example:
Challenge is a random string of characters such as abcdefg, ageksido Response is some function of that string such as bdf, gkip
Can alter algorithm based on ancillary information

Network connection is as above, dial-up might require aceg, aesd
Usually used in conjunction with fixed, reusable password

One-Time Passwords
Password that can be used exactly once
After use, it is immediately invalidated
Challenge-response mechanism
Challenge is number of authentications; response is password for that particular number
Problems
Synchronization of user, system Generation of good random passwords Password distribution problem
November 1, 2004
Slide #1-374
S/Key
One-time password scheme based on idea of Lamport h one-way hash function (MD5 or SHA-1, for example) User chooses initial seed k System calculates:
h(k) = k1, h(k1) = k2, , h(kn1) = kn
Passwords are reverse order:

p1 = kn, p2 = kn1, , pn1 = k2, pn = k1
S/Key Protocol
System stores maximum number of authentications n, number of next authentication i, last correctly supplied password pi1. user user user
{ name } {i} { pi }
system system system
System computes h(pi) = h(kni+1) = kni = pi1. If match with what is stored, system replaces pi1 with pi and increments i.
Hardware Support
Token-based
Used to compute response to challenge
May encipher or hash challenge May require PIN from user
Temporally-based
Every minute (or so) different number shown
Computer knows what number to expect when
User enters number and fixed password

C-R and Dictionary Attacks

Same as for fixed passwords
Attacker knows challenge r and response f(r); if f encryption function, can try different keys
May only need to know form of response; attacker can tell if guess correct by looking to see if deciphered object is of right form Example: Kerberos Version 4 used DES, but keys had 20 bits of randomness; Purdue attackers guessed keys quickly because deciphered tickets had a fixed set of bits in some locations
Encrypted Key Exchange

Defeats off-line dictionary attacks Idea: random challenges enciphered, so attacker cannot verify correct decipherment of challenge Assume Alice, Bob share secret password s In what follows, Alice needs to generate a random public key p and a corresponding private key q Also, k is a randomly generated session key, and RA and RB are random challenges
November 1, 2004
Slide #1-379
EKE Protocol
Alice Alice
Alice || Es(p) Es(Ep(k))
Bob Bob
Now Alice, Bob share a randomly generated secret session key k Alice Alice Alice
November 1, 2004
Ek(RA) Ek(RARB) Ek(RB)

Bob Bob Bob

Slide #1-380
Biometrics
Automated measurement of biological, behavioral features that identify a person
Fingerprints: optical or electrical techniques
Maps fingerprint into a graph, then compares with database Measurements imprecise, so approximate matching algorithms used
Voices: speaker verification or recognition

Verification: uses statistical techniques to test hypothesis that speaker is who is claimed (speaker dependent) Recognition: checks content of answers (speaker independent)
November 1, 2004
Slide #1-381
Other Characteristics
Can use several other characteristics
Eyes: patterns in irises unique
Measure patterns, determine if differences are random; or correlate images using statistical tests
Faces: image, or specific characteristics like distance from nose to chin

Lighting, view of face, other noise can hinder this
Keystroke dynamics: believed to be unique

Keystroke intervals, pressure, duration of stroke, where key is struck Statistical tests used
Cautions
These can be fooled!
Assumes biometric device accurate in the environment it is being used in! Transmission of data to validator is tamperproof, correct
November 1, 2004
Slide #1-383
Location
If you know where user is, validate identity by seeing if person is where the user is
Requires special-purpose hardware to locate user
GPS (global positioning system) device gives location signature of entity Host uses LSS (location signature sensor) to get signature for entity
November 1, 2004
Slide #1-384
Multiple Methods
Example: where you are also requires entity to have LSS and GPS, so also what you have Can assign different methods to different tasks
As users perform more and more sensitive tasks, must authenticate in more and more ways (presumably, more stringently) File describes authentication required
Also includes controls on access (time of day, etc.), resources, and requests to change passwords
Pluggable Authentication Modules
November 1, 2004
Slide #1-385
PAM
Idea: when program needs to authenticate, it checks central repository for methods to use Library call: pam_authenticate
Accesses file with name of program in /etc/pam_d
Modules do authentication checking

sufficient: succeed if module succeeds required: fail if module fails, but all required modules executed before reporting failure requisite: like required, but dont check all modules optional: invoke only if all previous modules fail
November 1, 2004
Slide #1-386
Example PAM File

auth suf f i c ient /us r / l ib /pam_f tp . so auth requ i red /us r / l ib /pam_un ix_auth .so use_f i rst_pass auth requ i red /us r / l ib /pam_l is t f i l e .so oner r=succeed \ i tem=user sense=deny f i l e=/e tc / f t pusers
For ftp: 1. If user anonymous, return okay; if not, set PAM_AUTHTOK to password, PAM_RUSER to name, and fail 2. Now check that password in PAM_AUTHTOK belongs to that of user in PAM_RUSER; if not, fail 3. Now see if user in PAM_RUSER named in /etc/ftpusers; if so, fail; if error or not found, succeed
Key Points
Authentication is not cryptography
You have to consider system components
Passwords are here to stay

They provide a basis for most forms of authentication
Protocols are important

They can make masquerading harder
Authentication methods can be combined

Example: PAM
November 1, 2004
Slide #1-388
Chapter 12: Design Principles

Overview Principles
Least Privilege Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least Common Mechanism Psychological Acceptability
November 1, 2004
Overview
Simplicity
Less to go wrong Fewer possible inconsistencies Easy to understand
Restriction
Minimize access Inhibit communication
Least Privilege
A subject should be given only those privileges necessary to complete its task
Function, not identity, controls Rights added as needed, discarded after use Minimal protection domain
November 1, 2004
Slide #1-391
Fail-Safe Defaults
Default action is to deny access If action fails, system as secure as when action began
November 1, 2004
Slide #1-392
Economy of Mechanism
Keep it as simple as possible
KISS Principle
Simpler means less can go wrong

And when errors occur, they are easier to understand and fix
Interfaces and interactions
November 1, 2004
Slide #1-393
Complete Mediation
Check every access Usually done once, on first action
UNIX: access checked on open, not checked thereafter
If permissions change after, may get unauthorized access
November 1, 2004
Slide #1-394
Open Design
Security should not depend on secrecy of design or implementation
Popularly misunderstood to mean that source code should be public Security through obscurity Does not apply to information such as passwords or cryptographic keys
November 1, 2004
Slide #1-395
Separation of Privilege
Require multiple conditions to grant privilege
Separation of duty Defense in depth
November 1, 2004
Slide #1-396
Least Common Mechanism

Mechanisms should not be shared
Information can flow along shared channels Covert channels
Isolation
Virtual machines Sandboxes
November 1, 2004
Slide #1-397
Psychological Acceptability
Security mechanisms should not add to difficulty of accessing resource
Hide complexity introduced by security mechanisms Ease of installation, configuration, use Human factors critical here
November 1, 2004
Slide #1-398
Key Points
Principles of secure design underlie all security-related mechanisms Require:
Good understanding of goal of mechanism and environment in which it is to be used Careful analysis and design Careful implementation
Chapter 13: Representing Identity

What is identity Multiple names for one thing Different contexts, environments Pseudonymity and anonymity
November 1, 2004
Slide #1-400
Overview
Files and objects Users, groups, and roles Certificates and names Hosts and domains State and cookies Anonymity
November 1, 2004
Identity
Principal: a unique entity Identity: specifies a principal Authentication: binding of a principal to a representation of identity internal to the system
All access, resource allocation decisions assume binding is correct
Files and Objects

Identity depends on system containing object Different names for one object
Human use, eg. file name Process use, eg. file descriptor or handle Kernel use, eg. file allocation table entry, inode
November 1, 2004
Slide #1-403
More Names
Different names for one context
Human: aliases, relative vs. absolute path names Kernel: deleting a file identified by name can mean two things:
Delete the object that the name identifies Delete the name given, and do not delete actual object until all names have been deleted
Semantics of names may differ

Example: Names and Descriptors

Interpretation of UNIX file name
Kernel maps name into an inode using iterative procedure Same name can refer to different objects at different times without being deallocated
Causes race conditions
Interpretation of UNIX file descriptor

Refers to a specific inode Refers to same inode from creation to deallocation
Example: Different Systems

Object name must encode location or pointer to location
rsh, ssh style: host:object URLs: protocol://host/object
Need not name actual object

rsh, ssh style may name pointer (link) to actual object URL may forward to another host
Users
Exact representation tied to system Example: UNIX systems
Login name: used to log in to system
Logging usually uses this name
User identification number (UID): unique integer assigned to user

Kernel uses UID to identify users One UID per login name, but multiple login names may have a common UID
Multiple Identities
UNIX systems again
Real UID: user identity at login, but changeable Effective UID: user identity used for access control
Setuid changes effective UID
Saved UID: UID before last change of UID

Used to implement least privilege Work with privileges, drop them, reclaim them later
Audit/Login UID: user identity used to track original UID

Cannot be altered; used to tie actions to login identity
Groups
Used to share access privileges First model: alias for set of principals
Processes assigned to groups Processes stay in those groups for their lifetime
Second model: principals can change groups

Rights due to old group discarded; rights due to new group added
Roles
Group with membership tied to function
Rights given are consistent with rights needed to perform function
Uses second model of groups Example: DG/UX

User root does not have administration functionality System administrator privileges are in sysadmin role Network administration privileges are in netadmin role Users can assume either role as needed
November 1, 2004
Naming and Certificates

Certificates issued to a principal
Principal uniquely identified to avoid confusion
Problem: names may be ambiguous

Does the name Matt Bishop refer to:
The author of this book? A programmer in Australia? A stock car driver in Muncie, Indiana? Someone else who was named Matt Bishop
November 1, 2004
Disambiguating Identity
Include ancillary information in names
Enough to identify principal uniquely X.509v3 Distinguished Names do this
Example: X.509v3 Distinguished Names

/O=University of California/OU=Davis campus/OU=Department of Computer Science/CN=Matt Bishop/ refers to the Matt Bishop (CN is common name) in the Department of Computer Science (OU is organizational unit) on the Davis Campus of the University of California (O is organization)
CAs and Policies

Matt Bishop wants a certificate from Certs-fromUs
How does Certs-from-Us know this is Matt Bishop?
CAs authentication policy says what type and strength of authentication is needed to identify Matt Bishop to satisfy the CA that this is, in fact, Matt Bishop
Will Certs-from-Us issue this Matt Bishop a certificate once he is suitably authenticated?
CAs issuance policy says to which principals the CA will issue certificates
Example: Verisign CAs

Class 1 CA issued certificates to individuals
Authenticated principal by email address
Idea: certificate used for sending, receiving email with various security services at that address

Authenticated by verifying user-supplied real name and address through an online database
Idea: certificate used for online purchasing
Example: Verisign CAs

Authenticated by background check from investigative service
Idea: higher level of assurance of identity than Class 1 and Class 2 CAs
Fourth CA issued certificates to web servers

Same authentication policy as Class 3 CA
Idea: consumers using these sites had high degree of assurance the web site was not spoofed
Internet Certification Hierarchy

Tree structured arrangement of CAs
Root is Internet Policy Registration Authority, or IPRA
Sets policies all subordinate CAs must follow Certifies subordinate CAs (called policy certification authorities, or PCAs), each of which has own authentication, issuance policies Does not issue certificates to individuals or organizations other than subordinate CAs
PCAs issue certificates to ordinary CAs

Does not issue certificates to individuals or organizations other than subordinate CAs
CAs issue certificates to organizations or individuals

Example
University of Valmont issues certificates to students, staff
Students must present valid reg cards (considered low assurance) Staff must present proof of employment and fingerprints, which are compared to those taken when staff member hired (considered high assurance)
UValmont and PCAs

First PCA: requires subordinate CAs to make good-faith effort to verify identities of principals to whom it issues certificates
Student authentication requirements meet this
Second PCA: requires use of biometrics to verify identity

Student authentication requirements do not meet this Staff authentication requirements do meet this
UValmont establishes to CAs, one under each PCA above

UValmont and Certification Hierarchy

low assurance PCA PCA-1 IPRA high assurance PCA PCA-2
UValmont Student CA student

November 1, 2004
UValmont Staff CA staff
student
staff
Slide #1-419
Certificate Differences
Student, staff certificates signed using different private keys (for different CAs)
Students signed by key corresponding to low assurance certificate signed by first PCA Staffs signed by key corresponding to high assurance certificate signed by second PCA
To see what policy used to authenticate:

Determine CA signing certificate, check its policy Also go to PCA that signed CAs certificate
CAs are restricted by PCAs policy, but CA can restrict itself further
Types of Certificates
Organizational certificate
Issued based on principals affiliation with organization Example Distinguished Name /O=University of Valmont/OU=Computer Science Department/CN=Marsha Merteuille/
Residential certificate
Issued based on where principal lives No affiliation with organization implied Example Distinguished Name /C=US/SP=Louisiana/L=Valmont/PA=1 Express Way/CN=Marsha Merteuille/
November 1, 2004
Slide #1-421
Certificates for Roles

Certificate tied to a role Example
UValmont wants comptroller to have a certificate
This way, she can sign contracts and documents digitally
Distinguished Name /O=University of Valmont/OU=Office of the Big Bucks/RN=Comptroller where RN is role name; note the individual using the certificate is not named, so no CN
Meaning of Identity
Authentication validates identity
CA specifies type of authentication If incorrect, CA may misidentify entity unintentionally
Certificate binds external identity to crypto key and Distinguished Name

Need confidentiality, integrity, anonymity
Recipient knows same entity sent all messages, but not who that entity is
Persona Certificate
Certificate with meaningless Distinguished Name
If DN is /C=US/O=Microsoft Corp./CN=Bill Gates/ the real subject may not (or may) be Mr. Gates Issued by CAs with persona policies under a PCA with policy that supports this
PGP certificates can use any name, so provide this implicitly

Example
Government requires all citizens with gene X to register
Anecdotal evidence people with this gene become criminals with probability 0.5. Law to be made quietly, as no scientific evidence supports this, and government wants no civil rights fuss
Government employee wants to alert media

Government will deny plan, change approach Government employee will be fired, prosecuted
Must notify media anonymously

Example
Employee gets persona certificate, sends copy of plan to media
Media knows message unchanged during transit, but not who sent it Government denies plan, changes it
Employee sends copy of new plan signed using same certificate

Media can tell its from original whistleblower Media cannot track back whom that whistleblower is
Trust
Goal of certificate: bind correct identity to DN Question: what is degree of assurance? X.509v3, certificate hierarchy
Depends on policy of CA issuing certificate Depends on how well CA follows that policy Depends on how easy the required authentication can be spoofed
Really, estimate based on the above factors

Example: Passport Required

DN has name on passport, number and issuer of passport What are points of trust?
Passport not forged and name on it not altered Passport issued to person named in passport Person presenting passport is person to whom it was issued CA has checked passport and individual using passport
November 1, 2004
Slide #1-428
PGP Certificates
Level of trust in signature field Four levels
Generic (no trust assertions made) Persona (no verification) Casual (some verification) Positive (substantial verification)
What do these mean?

Meaning not given by OpenPGP standard Signer determines what level to use Casual to one signer may be positive to another
Identity on the Web

Host identity
Static identifiers: do not change over time Dynamic identifiers: changes as a result of an event or the passing of time
State and Cookies Anonymity

Anonymous email Anonymity: good or bad?
Host Identity
Bound up to networking
Not connected: pick any name Connected: one or more names depending on interfaces, network structure, context
Name identifies principal Address identifies location of principal

May be virtual location (network segment) as opposed to physical location (room 222)
Example
Layered network
MAC layer
Ethernet address: 00:05:02:6B:A8:21 AppleTalk address: network 51, node 235
Network layer
IP address: 192.168.35.89
Transport layer
Host name: cherry.orchard.chekhov.ru
Danger!
Attacker spoofs identity of another host
Protocols at, above the identity being spoofed will fail They rely on spoofed, and hence faulty, information
Example: spoof IP address, mapping between host names and IP addresses

Domain Name Server

Maps transport identifiers (host names) to network identifiers (host addresses)
Forward records: host names IP addresses Reverse records: IP addresses host names
Weak authentication
Not cryptographically based Various techniques used, such as reverse domain name lookup
Reverse Domain Name Lookup

Validate identity of peer (host) name
Get IP address of peer Get associated host name via DNS Get IP addresses associated with host name from DNS If first IP address in this set, accept name as correct; otherwise, reject as spoofed
If DNS corrupted, this wont work

Dynamic Identifiers
Assigned to principals for a limited time
Server maintains pool of identifiers Client contacts server using local identifier
Only client, server need to know this identifier
Server sends client global identifier

Client uses global identifier in other contexts, for example to talk to other hosts Server notifies intermediate hosts of new client, global identifier association
Example: DHCP
DHCP server has pool of IP addresses Laptop sends DHCP server its MAC address, requests IP address
MAC address is local identifier IP address is global identifier
DHCP server sends unused IP address

Also notifies infrastructure systems of the association between laptop and IP address
Laptop accepts IP address, uses that to communicate with hosts other than server
Example: Gateways
Laptop wants to access host on another network
Laptops address is 10.1.3.241
Gateway assigns legitimate address to internal address

Say IP address is 101.43.21.241 Gateway rewrites all outgoing, incoming packets appropriately Invisible to both laptop, remote peer
Internet protocol NAT works this way

Weak Authentication
Static: host/name binding fixed over time Dynamic: host/name binding varies over time
Must update reverse records in DNS
Otherwise, the reverse lookup technique fails
Cannot rely on binding remaining fixed unless you know the period of time over which the binding persists
DNS Security Issues

Trust is that name/IP address binding is correct Goal of attacker: associate incorrectly an IP address with a host name
Assume attacker controls name server, or can intercept queries and send responses
November 1, 2004
Slide #1-440
Attacks
Change records on server Add extra record to response, giving incorrect name/IP address association
Called cache poisoning
Attacker sends victim request that must be resolved by asking attacker

Attacker responds with answer plus two records for address spoofing (1 forward, 1 reverse) Called ask me
Cookies
Token containing information about state of transaction on network
Usual use: refers to state of interaction between web browser, client Idea is to minimize storage requirements of servers, and put information on clients
Client sends cookies to server

Some Fields in Cookies

name, value: name has given value expires: how long cookie valid
Expired cookies discarded, not sent to server If omitted, cookie deleted at end of session
domain: domain for which cookie intended

Consists of last n fields of domain name of server Must have at least one . in it
secure: send only over secured (SSL, HTTPS) connection

Example
Caroline puts 2 books in shopping cartcart at books.com
Cookie: name bought, value BK=234&BK=8753, domain .books.com
Caroline looks at other books, but decides to buy only those

She goes to the purchase page to order them
Server requests cookie, gets above

From cookie, determines books in shopping cart
Who Can Get the Cookies?

Web browser can send any cookie to a web server
Even if the cookies domain does not match that of the web server Usually controlled by browser settings
Web server can only request cookies for its domain

Cookies need not have been sent by that browser
November 1, 2004
Slide #1-445
Where Did the Visitor Go?

Server books.com sends Caroline 2 cookies
First described earlier Second has name id, value books.com, domain adv.com
Advertisements at books.com include some from site adv.com

When drawing page, Carolines browser requests content for ads from server adv.com Server requests cookies from Carolines browser By looking at value, server can tell Caroline visited books.com
Anonymity on the Web

Recipients can determine origin of incoming packet
Sometimes not desirable
Anonymizer: a site that hides origins of connections

Usually a proxy server
User connects to anonymizer, tells it destination Anonymizer makes connection, sends traffic in both directions
Destination host sees only anonymizer

Example: anon.penet.fi
Offered anonymous email service
Sender sends letter to it, naming another destination Anonymizer strips headers, forwards message
Assigns an ID (say, 1234) to sender, records real sender and ID in database Letter delivered as if from anon1234@anon.penet.fi
Recipient replies to that address

Anonymizer strips headers, forwards message as indicated by database entry
November 1, 2004
Slide #1-448
Problem
Anonymizer knows who sender, recipient really are Called pseudo-anonymous remailer or pseudonymous remailer
Keeps mappings of anonymous identities and associated identities
If you can get the mappings, you can figure out who sent what
More anon.penet.fi
Material claimed to be copyrighted sent through site Finnish court directed owner to reveal mapping so plaintiffs could determine sender Owner appealed, subsequently shut down site
Cypherpunk Remailer
Remailer that deletes header of incoming message, forwards body to destination Also called Type I Remailer No record kept of association between sender address, remailers user name
Prevents tracing, as happened with anon.penet.fi
Usually used in a chain, to obfuscate trail

For privacy, body of message may be enciphered
Cypherpunk Remailer Message

send to remailer 1 send to remailer 2 send to Alice Hi, Alice, Its SQUEAMISH OSSIFRIGE Bob
Encipher message Add destination header Add header for remailer n Add header for remailer 2
Slide #1-452
November 1, 2004
Weaknesses
Attacker monitoring entire network
Observes in, out flows of remailers Goal is to associate incoming, outgoing messages
If messages are cleartext, trivial

So assume all messages enciphered
So use traffic analysis!

Used to determine information based simply on movement of messages (traffic) around the network
Attacks
If remailer forwards message before next message arrives, attacker can match them up
Hold messages for some period of time, greater than the message interarrival time Randomize order of sending messages, waiting until at least n messages are ready to be forwarded
Note: attacker can force this by sending n1 messages into queue
November 1, 2004
Slide #1-454
Attacks
As messages forwarded, headers stripped so message size decreases
Pad message with garbage at each step, instructing next remailer to discard it
Replay message, watch for spikes in outgoing traffic

Remailer cant forward same message more than once
Mixmaster Remailer
Cypherpunk remailer that handles only enciphered mail and pads (or fragments) messages to fixed size before sending them
Also called Type II Remailer Designed to hinder attacks on Cypherpunk remailers
Messages uniquely numbered Fragments reassembled only at last remailer for sending to recipient
Cypherpunk Remailer Message

enciphered with RSA for remailer #1 remailer #2 address packet ID: 135 Triple DES key: 1 enciphered with Triple DES key #1 enciphered with RSA for remailer #2 final hop address packet ID: 168 message ID: 7839 Triple DES key: 2 random garbage enciphered with Triple DES key #2 recipents address any mail headers to add message padding if needed
November 1, 2004
Slide #1-457
Anonymity Itself
Some purposes for anonymity
Removes personalities from debate With appropriate choice of pseudonym, shapes course of debate by implication Prevents retaliation
Are these benefits or drawbacks?

Depends on society, and who is involved
Privacy
Anonymity protects privacy by obstructing amalgamation of individual records Important, because amalgamation poses 3 risks:
Incorrect conclusions from misinterpreted data Harm from erroneous information Not being let alone
Also hinders monitoring to deter or prevent crime Conclusion: anonymity can be used for good or ill
Right to remain anonymous entails responsibility to use that right wisely
Key Points
Identity specifies a principal (unique entity)
Same principal may have many different identities
Function (role) Associated principals (group) Individual (user/host)
These may vary with view of principal

Different names at each network layer, for example
Anonymity possible; may or may not be desirable

Power to remain anonymous includes responsibility to use that power wisely
November 1, 2004
Slide #1-460
Chapter 14: Access Control Mechanisms

Access control lists Capabilities Locks and keys Ring-based access control Propagated access control lists
November 1, 2004
Slide #1-461
Overview
Access control lists Capability lists Locks and keys Rings-based access control Propagated access control lists
November 1, 2004
Slide #1-462
Access Control Lists

Columns of access control matrix file1 file2 file3 Andy rx r rwo Betty rwxo r Charlie rx rwo w ACLs: file1: { (Andy, rx) (Betty, rwxo) (Charlie, rx) } file2: { (Andy, r) (Betty, r) (Charlie, rwo) } file3: { (Andy, rwo) (Charlie, w) }
Default Permissions
Normal: if not named, no rights over file
Principle of Fail-Safe Defaults
If many subjects, may use groups or wildcards in ACL

UNICOS: entries are (user, group, rights)
If user is in group, has rights over file * is wildcard for user, group
(holly, *, r): holly can read file regardless of her group (*, gleep, w): anyone in group gleep can write file
Abbreviations
ACLs can be long so combine users
UNIX: 3 classes of users: owner, group, rest rwx rwx rwx rest group owner Ownership assigned based on creating process
Some systems: if directory has setgid permission, file group owned by group of directory (SunOS, Solaris)
November 1, 2004
Slide #1-465
ACLs + Abbreviations
Augment abbreviated lists with ACLs
Intent is to shorten ACL
ACLs override abbreviations

Exact method varies
Example: IBM AIX

Base permissions are abbreviations, extended permissions are ACLs with user, group ACL entries can add rights, but on deny, access is denied
November 1, 2004
Slide #1-466
Permissions in IBM AIX

at t r ibutes : base permiss ions owner (b ishop) : group(sys) : others : extended permiss ions spec i f y permit permit deny
November 1, 2004
rwr enabl ed rwu:ho l l y -wu:he i d i , g=sys rwu:matt -wu:ho l l y , g= f acu l t y

Slide #1-467
ACL Modification
Who can do this?
Creator is given own right that allows this System R provides a grant modifier (like a copy flag) allowing a right to be transferred, so ownership not needed
Transferring right to another modifies ACL
November 1, 2004
Slide #1-468
Privileged Users
Do ACLs apply to privileged users (root)?
Solaris: abbreviated lists do not, but full-blown ACL entries do Other vendors: varies
November 1, 2004
Slide #1-469
Groups and Wildcards

Classic form: no; in practice, usually
AIX: base perms gave group sys read only
permi t -wu:he id i , g=sys
line adds write permission for heidi when in that group UNICOS:
holly : gleep : r
user holly in group gleep can read file
holly : * : r
user holly in any group can read file
* : gleep : r
any user in group gleep can read file
Conflicts
Deny access if any entry would deny access
AIX: if any entry denies access, regardless or rights given so far, access is denied
Apply first entry matching subject

Cisco routers: run packet through access control rules (ACL entries) in order; on a match, stop, and forward the packet; if no matches, deny
Note default is deny so honors principle of fail-safe defaults
November 1, 2004
Slide #1-471
Handling Default Permissions

Apply ACL entry, and if none use defaults
Cisco router: apply matching access control rule, if any; otherwise, use default rule (deny)
Augment defaults with those in the appropriate ACL entry

AIX: extended permissions augment base permissions
Revocation Question
How do you remove subjects rights to a file?
Owner deletes subjects entries from ACL, or rights from subjects entry in ACL
What if ownership not involved?

Depends on system System R: restore protection state to what it was before right was given
May mean deleting descendent rights too
Windows NT ACLs
Different sets of rights
Basic: read, write, execute, delete, change permission, take ownership Generic: no access, read (read/execute), change (read/write/execute/delete), full control (all), special access (assign any of the basics) Directory: no access, read (read/execute files in directory), list, add, add and read, change (create, add, read, execute, write files; delete subdirectories), full control, special access
November 1, 2004
Slide #1-474
Accessing Files
User not in files ACL nor in any group named in files ACL: deny access ACL entry denies user access: deny access Take union of rights of all ACL entries giving user access: user has this set of rights over file
November 1, 2004
Slide #1-475
Capability Lists
Rows of access control matrix file1 file2 file3 Andy rx r rwo Betty rwxo r Charlie rx rwo w C-Lists: Andy: { (file1, rx) (file2, r) (file3, rwo) } Betty: { (file1, rwxo) (file2, r) } Charlie: { (file1, rx) (file2, rwo) (file3, w) }
Semantics
Like a bus ticket
Mere possession indicates rights that subject has over object Object identified by capability (as part of the token)
Name may be a reference, location, or something else
Architectural construct in capability-based addressing; this just focuses on protection aspects
Must prevent process from altering capabilities

Otherwise subject could change rights encoded in capability or object to which they refer
Implementation
Tagged architecture
Bits protect individual words
B5700: tag was 3 bits and indicated how word was to be treated (pointer, type, descriptor, etc.)
Paging/segmentation protections
Like tags, but put capabilities in a read-only segment or page
CAP system did this
Programs must refer to them by pointers

Otherwise, program could use a copy of the capabilitywhich it could modify
Implementation (cont)
Cryptography
Associate with each capability a cryptographic checksum enciphered using a key known to OS When process presents capability, OS validates checksum Example: Amoeba, a distributed capability-based system
Capability is (name, creating_server, rights, check_field) and is given to owner of object check_field is 48-bit random number; also stored in table corresponding to creating_server To validate, system compares check_field of capability with that stored in creating_server table Vulnerable if capability disclosed to another process
November 1, 2004
Slide #1-479
Amplifying
Allows temporary increase of privileges Needed for modular programming
Module pushes, pops data onto stack
module s tack endmodule.
Variable x declared of type stack

var x : module;
Only stack module can alter, read x

So process doesnt get capability, but needs it when x is referenced a problem!
Solution: give process the required capabilities while it is in module
November 1, 2004
Slide #1-480
Examples
HYDRA: templates
Associated with each procedure, function in module Adds rights to process capability while the procedure or function is being executed Rights deleted on exit
Intel iAPX 432: access descriptors for objects

These are really capabilities 1 bit in this controls amplification When ADT constructed, permission bits of type control object set to what procedure needs On call, if amplification bit in this permission is set, the above bits ored with rights in access descriptor of object being passed
Revocation
Scan all C-lists, remove relevant capabilities
Far too expensive!
Use indirection
Each object has entry in a global object table Names in capabilities name the entry, not the object
To revoke, zap the entry in the table Can have multiple entries for a single object to allow control of different sets of rights and/or groups of users for each object
Example: Amoeba: owner requests server change random number in server table
All capabilities for that object now invalid
November 1, 2004
Slide #1-482
Limits
Problems if you dont control copying of capabilities
Heidi (High) C-List r*lough Lough (Low) rw*lough Lou (Low) C-List rw*lough Lou (Low) Heidi (High) C-List r*lough Lough (Low) rw*lough rw*lough C-List rw*lough
The capability to write file lough is Low, and Heidi is High so she reads (copies) the capability; now she can write to a Low file, violating the *-property!
Remedies
Label capability itself
Rights in capability depends on relation between its compartment and that of object to which it refers
In example, as as capability copied to High, and High dominates object compartment (Low), write right removed
Check to see if passing capability violates security properties

In example, it does, so copying refused
Distinguish between read and copy capability

Take-Grant Protection Model does this (read, take)
ACLs vs. Capabilities

Both theoretically equivalent; consider 2 questions
1. Given a subject, what objects can it access, and how? 2. Given an object, what subjects can access it, and how? ACLs answer second easily; C-Lists, first
Suggested that the second question, which in the past has been of most interest, is the reason ACLbased systems more common than capability-based systems
As first question becomes more important (in incident response, for example), this may change
Locks and Keys

Associate information (lock) with object, information (key) with subject
Latter controls what the subject can access and how Subject presents key; if it corresponds to any of the locks on the object, access granted
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)
November 1, 2004
Slide #1-486
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))))
Example: IBM
IBM 370: process gets access key; pages get storage key and fetch bit
Fetch bit clear: read access only Fetch bit set, access key 0: process can write to (any) page Fetch bit set, access key matches storage key: process can write to page Fetch bit set, access key non-zero and does not match storage key: no access allowed
Example: Cisco Router

Dynamic access control lists
accessl i s t100 permi tt cp any host 10 .1 .1 .1 eq te lne t accessl i s t100 dynami ctes tt imeout 180 permitip any host \ 10.1 .2 .3 t i me-range myt ime t imerange myt ime per iod ic weekdays 9 :00 to 17 :00 l i ne v ty 0 2 l og in loca l autocom m and access-enab le hos tt imeout 10
Limits external access to 10.1.2.3 to 9AM5PM

Adds temporary entry for connecting host once user supplies name, password to router Connections good for 180 minutes
Drops access control entry after that
Type Checking
Lock is type, key is operation
Example: UNIX system call write cant work on directory object but does work on file Example: split I&D space of PDP-11 Example: countering buffer overflow attacks on the stack by putting stack on non-executable pages/segments
Then code uploaded to buffer wont execute Does not stop other forms of this attack, though
More Examples
LOCK system:
Compiler produces data Trusted process must change this type to executable becore program can be executed
Sidewinder firewall
Subjects assigned domain, objects assigned type
Example: ingress packets get one type, egress packets another
All actions controlled by type, so ingress packets cannot masquerade as egress packets (and vice versa)
November 1, 2004
Slide #1-491
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
Slide #1-492
Privileges increase
0 1
November 1, 2004
Reading/Writing/Appending
Procedure executing in ring r Data segment with access bracket (a1, a2) Mandatory access rule
r a1 allow access a1 < r a2 allow r access; not w, a access a2 < r deny all access
November 1, 2004
Slide #1-493
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 < a1 a1 r a2 a2 < r a3 a3 < r allow access; ring-crossing fault allow access; no ring-crossing fault allow access if through valid gate deny all access
November 1, 2004
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
PACLs
Propagated Access Control List
Implements ORGON
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
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
November 1, 2004
Slide #1-497
Key Points
Access control mechanisms provide controls for users accessing files Many different forms
ACLs, capabilities, locks and keys
Type checking too
Ring-based mechanisms (Mandatory) PACLs (ORCON)

Chapter 15: Information Flow

Definitions Compiler-based mechanisms Execution-based mechanisms Examples
November 1, 2004
Slide #1-499
Overview
Basics and background Compiler-based mechanisms Execution-based mechanisms Examples
Security Pipeline Interface Secure Network Server Mail Guard
November 1, 2004
Slide #1-500
Basics
Bell-LaPadula Model embodies information flow policy
Given compartments A, B, info can flow from A to B iff B dom A
Variables x, y assigned compartments x, y as well as values

If x = A and y = B, and A dom B, then y := x allowed but not x := y
Information Flow
Idea: info flows from x to y as a result of a sequence of commands c if you can deduce information about x before c from the value in y after c
November 1, 2004
Slide #1-502
Example 1
Command is x := y + z; where:
0 y 7, equal probability z = 1 with prob. 1/2, z = 2 or 3 with prob. 1/4 each
If you know final value of x, initial value of y can have at most 3 values, so information flows from y to x
Example 2
Command is
if x = 1 then y := 0 else y := 1;
where:
x, y equally likely to be either 0 or 1
But if x = 1 then y = 0, and vice versa, so value of y depends on x So information flowed from x to y
Implicit Flow of Information

Information flows from x to y without an explicit assignment of the form y := f(x)
f(x) an arithmetic expression with variable x
Example from previous slide:

if x = 1 then y := 0 else y := 1;
So must look for implicit flows of information to analyze program

Notation
x means class of x
In Bell-LaPadula based system, same as label of security compartment to which x belongs
x y means information can flow from an element in class of x to an element in class of y

Or, information with a label placing it in class x can flow into class y
Compiler-Based Mechanisms
Detect unauthorized information flows in a program during compilation Analysis not precise, but secure
If a flow could violate policy (but may not), it is unauthorized No unauthorized path along which information could flow remains undetected
Set of statements certified with respect to information flow policy if flows in set of statements do not violate that policy
Example
i fx= 1 t hen y := a; else y := b;
Info flows from x and a to y, or from x and b to y Certified only if x y and a y and b y
Note flows for both branches must be true unless compiler can determine that one branch will never be taken
Declarations
Notation:
x : int c lass { A, B }
means x is an integer variable with security class at least lub{ A, B }, so lub{ A, B } x Distinguished classes Low, High
Constants are always Low
November 1, 2004
Slide #1-509
Input Parameters
Parameters through which data passed into procedure Class of parameter is class of actual argument
i :type c l ass { i p p}
November 1, 2004
Slide #1-510
Output Parameters
Parameters through which data passed out of procedure
If data passed in, called input/output parameter
As information can flow from input parameters to output parameters, class must include this: ype class { r1, , rn } op: t where ri is class of ith input or input/output argument
Example
proc sum (x :i nt c l ass { A } ; var out :in t class { A ,B } ) ; begin out : = out + x ; end;
Require x out and out out
November 1, 2004
Slide #1-512
Array Elements
Information flowing out:
:= a [ i ]
Value of i, a[i] both affect result, so class is lub{ a[i], i } Information flowing in:
a[ i ]: =
Only value of a[i] affected, so class is a[i]

Assignment Statements
x := y + z;
Information flows from y, z to x, so this requires lub{ y, z } x More generally:

y := f (x1 , , xn)
the relation lub{ x1, , xn } y must hold
November 1, 2004
Slide #1-514
Compound Statements
x := y + z; a := b * c x;
First statement: lub{ y, z } x Second statement: lub{ b, c, x } a So, both must hold (i.e., be secure) More generally:
S1; S n;
Each individual Si must be secure

Conditional Statements
i f x + y < z then a := b e lse d := b * c x ; end
The statement executed reveals information about x, y, z, so lub{ x, y, z } glb{ a, d } More generally: i ff (x1, , xn) then S1 el se S2; end S1, S2 must be secure lub{ x1, , xn } glb{y | y target of assignment in S1, S2 }
Iterative Statements
whi le i< n do beg in a[ i ]:= b[ i ] ;i: =i+ 1 ; end
Same ideas as for if, but must terminate More generally:

whi le f (x1 , , xn) do S;
Loop must terminate; S must be secure lub{ x1, , xn } glb{y | y target of assignment in S }
Iterative Statements
whi le i< n do beg in a[ i ]:= b [ i ] ;i:= i+ 1 ; end
Same ideas as for if, but must terminate More generally:

whi le f (x1 , , xn) do S ;
Loop must terminate; S must be secure lub{ x1, , xn } glb{y | y target of assignment in S }
November 1, 2004
Slide #1-518
Goto Statements
No assignments
Hence no explicit flows
Need to detect implicit flows Basic block is sequence of statements that have one entry point and one exit point
Control in block always flows from entry point to exit point
Example Program
proc t m(x: ar ray [1 . .10 ] [1 . . 10] o fi nt c lass {x } ; var y :a r ray [1 . .10] [1 . .10 ]o fin tc lass { y} ) ; var i ,j :in t{ i } ; beg in b1 i:= 1; b2 L2 : i fi > 10 go to L7; b3 j:= 1; b4 L4 : i fj > 10 then goto L6; b5 y [ j ] [ i ]:= x [ i ] [ j ] ;j:= j + 1; go to L4 ; b6 L6 : i:= i + 1 ; go t o L2 ; b7 L7 : end;
Flow of Control
b1 b6
j>n
b2
i>n in
b7 b3
b4
jn
b5
IFDs
Idea: when two paths out of basic block, implicit flow occurs
Because information says which path to take
When paths converge, either:

Implicit flow becomes irrelevant; or Implicit flow becomes explicit
Immediate forward dominator of basic block b (written IFD(b)) is first basic block lying on all paths of execution passing through b
IFD Example
In previous procedure:
IFD(b1) = b2 IFD(b2) = b7 IFD(b3) = b4 IFD(b4) = b6 IFD(b5) = b4 IFD(b6) = b2 one path b2b7 or b2b3b6b2b7 one path b4b6 or b4b5b6 one path one path
November 1, 2004
Requirements
Bi is set of basic blocks along an execution path from bi to IFD(bi)
Analogous to statements in conditional statement
xi1, , xin variables in expression selecting which execution path containing basic blocks in Bi used
Analogous to conditional expression
Requirements for secure:

All statements in each basic blocks are secure lub{ xi1, , xin } glb{ y | y target of assignment in Bi }
Example of Requirements
Within each basic block:
b1: Low i b3: Low j b6: lub{ Low, i } i b5: lub{ x[i][j], i, j } y[j][i] }; lub{ Low, j } j Combining, lub{ x[i][j], i, j } y[j][i] } From declarations, true when lub{ x, i } y
B2 = {b3, b4, b5, b6}

Assignments to i, j, y[j][i]; conditional is i 10 Requires i glb{ i, j, y[j][i] } From declarations, true when i y
Example (continued)
B4 = { b 5 }
Assignments to j, y[j][i]; conditional is j 10 Requires j glb{ j, y[j][i] } From declarations, means i y
Result:
Combine lub{ x, i } y; i y; i y Requirement is lub{ x, i } y
Procedure Calls
tm(a , b) ;
From previous slides, to be secure, lub{ x, i } y must hold In call, x corresponds to a, y to b Means that lub{ a, i } b, or a b More generally:
proc pn( i1 , ,im :in t ; var o1, , on: in t ) beg in S end;
S must be secure For all j and k, if ij ok, then xj yk For all j and k, if oj ok, then yj yk
Exceptions
proc copy(x :in tc l ass { x } ; var y :in tc lass Low) var sum: in tc lass { x } ; z :i nt c lass Low; beg in y: = z := sum : =0 ; whi l e z = 0 do beg in sum : = sum + x ; y := y + 1 ; end end
Exceptions (cont)
When sum overflows, integer overflow trap
Procedure exits Value of x is MAXINT/y Info flows from y to x, but x y never checked
Need to handle exceptions explicitly

Idea: on integer overflow, terminate loop
on in teger_over f low_except ion sum do z := 1 ;
Now info flows from sum to z, meaning sum z This is false (sum = { x } dominates z = Low)
Infinite Loops
proc copy(x :in t0 . . 1c lass { x } ; var y :in t0 . .1 cl ass Low) beg in y: =0 ; whi l e x = 0 do ( * no t h ing * ) ; y: =1 ; end
If x = 0 initially, infinite loop If x = 1 initially, terminates with y set to 1 No explicit flows, but implicit flow from x to y
Slide #1-530
Semaphores
Use these constructs:
wai t (x ) : i f x = 0 then b lock unt i l x > 0; x := x 1 ; s igna l ( x) : x := x + 1 ;
x is semaphore, a shared variable Both executed atomically
Consider statement
wai t ( sem) ; x := x + 1 ;
Implicit flow from sem to x

Certification must take this into account!
Flow Requirements
Semaphores in signal irrelevant
Dont affect information flow in that process
Statement S is a wait
shared(S): set of shared variables read
Idea: information flows out of variables in shared(S)
fglb(S): glb of assignment targets following S So, requirement is shared(S) fglb(S)
begin S1; Sn end
All Si must be secure For all i, shared(Si) fglb(Si)

November 1, 2004
Example
beg in x := y + z ; ( * S1 * ) ) wa i t (sem ) ; ( * S2 * ) a: = b *c x ; ( * S3 * end
Requirements:
lub{ y, z } x lub{ b, c, x } a sem a
Because fglb(S2) = a and shared(S2) = sem
Concurrent Loops
Similar, but wait in loop affects all statements in loop
Because if flow of control loops, statements in loop before wait may be executed after wait
Requirements
Loop terminates All statements S1, , Sn in loop secure lub{ shared(S1), , shared(Sn) } glb(t1, , tm)
Where t1, , tm are variables assigned to in loop
Loop Example
whi le i < n do beg in a [ i ]:= i tem; ( * S1 * ) wai t ( sem); ( * S2 * ) i:= i + 1 ; ( * S3 * ) end
Conditions for this to be secure:

Loop terminates, so this condition met S1 secure if lub{ i, item } a[i] S2 secure if sem i and sem a[i] S3 trivially secure
November 1, 2004
cobegin/coend
cobeg in x: = y +z ; ( * S1 * ) a: = b *c y ; ( * S2 * ) coend
No information flow among statements

For S1, lub{ y, z } x For S2, lub{ b, c, y } a
Security requirement is both must hold

So this is secure if lub{ y, z } x lub{ b, c, y } a
Soundness
Above exposition intuitive Can be made rigorous:
Express flows as types Equate certification to correct use of types Checking for valid information flows same as checking types conform to semantics imposed by security policy
Execution-Based Mechanisms
Detect and stop flows of information that violate policy
Done at run time, not compile time
Obvious approach: check explicit flows

Problem: assume for security, x y i f x = 1 then y := a ; When x 1, x = High, y = Low, a = Low, appears okaybut implicit flow violates condition!
November 1, 2004
Slide #1-538
Fentons Data Mark Machine

Each variable has an associated class Program counter (PC) has one too Idea: branches are assignments to PC, so you can treat implicit flows as explicit flows Stack-based machine, so everything done in terms of pushing onto and popping from a program stack
Instruction Description
skip means instruction not executed push(x, x) means push variable x and its security class x onto program stack pop(x, x) means pop top value and security class from program stack, assign them to variable x and its security class x respectively
Instructions

x := x + 1 (increment) Same as: i f PC x then x := x + 1 e lse sk ip i f x = 0 then goto n e lse x := x 1
on stack)
(branch and save PC
Same as: i f x = 0 then beg in push(PC, PC); PC := lub{PC, x} ; PC : =n ; end el se i f PC x t hen x := x - 1 e lse sk ip ;
More Instructions
i f x = 0 then goto n el se x := x 1 (branch
without saving PC on stack)
Same as: i f x = 0 then i f x PC then PC := n e lse sk i p e lse i f PC x then x : = x -1 e lse sk i p
November 1, 2004
Slide #1-542
More Instructions

re turn
(go to just after last if)
Same as: ; pop(PC, PC) ha l t (stop) Same as: i fp rogram s tack empty then ha l t Note stack empty to prevent user obtaining information from it after halting
Example Program
1 2 3 4 5 6 7 i f x = 0 then got o4e l se x : = x -1 i f z = 0 then got o6e l se z : = z -1 ha l t z := z - 1 re tu r n y := y - 1 re tu r n Initially x = 0 or x = 1, y = 0, z = 0 Program copies value of x to y
November 1, 2004
Example Execution
x 1 0 0 0 0 y 0 0 0 1 1 z 0 0 0 0 0 PC 1 2 6 7 3 PC Low Low z z Low stack (3, Low) (3, Low) check Low x PC y
November 1, 2004
Slide #1-545
Handling Errors
Ignore statement that causes error, but continue execution
If aborted or a visible exception taken, user could deduce information Means errors cannot be reported unless user has clearance at least equal to that of the information causing the error
November 1, 2004
Slide #1-546
Variable Classes
Up to now, classes fixed
Check relationships on assignment, etc.
Consider variable classes

Fentons Data Mark Machine does this for PC On assignment of form y := f(x1, , xn), y changed to lub{ x1, , xn } Need to consider implicit flows, also
Example Program
( * Copy va lue f rom x to y *In i t ial l y , xi s0o r1* ) proc copy(x :i n tc lass { x } ; var y :i nt c lass { y } ) var z :i nt c lass var iab le { Low } ; beg in y := 0 ; z := 0 ; i f x = 0 then z := 1 ; i f z = 0 then y := 1 ; end;
z changes when z assigned to Assume y < x

Analysis of Example
x=0
z := 0 sets z to Low i f x = 0 then z := 1 sets z to 1 and z to x So on exit, y = 0
x=1
z := 0 sets z to Low i f z = 0 then y := 1 sets y to 1 and checks that lub{Low, z} y So on exit, y = 1
Information flowed from x to y even though y < x

Handling This (1)

Fentons Data Mark Machine detects implicit flows violating certification rules
November 1, 2004
Slide #1-550
Handling This (2)

Raise class of variables assigned to in conditionals even when branch not taken Also, verify information flow requirements even when branch not taken Example:
In i f x = 0 then z := 1, z raised to x whether or not x = 0 Certification check in next statement, that z y, fails, as z = x from previous statement, and y x
Handling This (3)

Change classes only when explicit flows occur, but all flows (implicit as well as explicit) force certification checks Example
When x = 0, first if sets z to Low then checks x z When x = 1, first if checks that x z This holds if and only if x = Low
Not possible as y < x = Low and there is no such class
November 1, 2004
Slide #1-552
Example Information Flow Control Systems

Use access controls of various types to inhibit information flows Security Pipeline Interface
Analyzes data moving from host to destination
Secure Network Server Mail Guard

Controls flow of data between networks that have different security classifications
Security Pipeline Interface

host SPI second disk first disk
SPI analyzes data going to, from host

No access to host main memory Host has no control over SPI
November 1, 2004
Slide #1-554
Use
Store files on first disk Store corresponding crypto checksums on second disk Host requests file from first disk
SPI retrieves file, computes crypto checksum SPI retrieves files crypto checksum from second disk If a match, file is fine and forwarded to host If discrepency, file is compromised and host notified
Integrity information flow restricted here

Corrupt file can be seen but will not be trusted
Secure Network Server Mail Guard (SNSMG)

MTA
SECRET computer
filters out in
MTA
UNCLASSIFIED computer
Filters analyze outgoing messages

Check authorization of sender Sanitize message if needed (words and viruses, etc.)
Uses type checking to enforce this

Incoming, outgoing messages of different type Only appropriate type can be moved in or out
Key Points
Both amount of information, direction of flow important
Flows can be explicit or implicit
Compiler-based checks flows at compile time Execution-based checks flows at run time
November 1, 2004
Slide #1-557
Chapter 16: Confinement Problem

What is the problem? Isolation: virtual machines, sandboxes Detecting covert channels Analyzing covert channels Mitigating covert channels
November 1, 2004
Slide #1-558
Overview
The confinement problem Isolating entities
Virtual machines Sandboxes
Covert channels
Detecting them Analyzing them Mitigating them
Example Problem
Server balances bank accounts for clients Server security issues:
Record correctly who used it Send only balancing info to client
Client security issues:

Log use correctly Do not save or retransmit data client sends
Generalization
Client sends request, data to server Server performs some function on data Server returns result to client Access controls:
Server must ensure the resources it accesses on behalf of client include only resources client is authorized to access Server must ensure it does not reveal clients data to any entity not authorized to see the clients data
Confinement Problem
Problem of preventing a server from leaking information that the user of the service considers confidential
November 1, 2004
Slide #1-562
Total Isolation
Process cannot communicate with any other process Process cannot be observed Impossible for this process to leak information
Not practical as process uses observable resources such as CPU, secondary storage, networks, etc.
Example
Processes p, q not allowed to communicate
But they share a file system!
Communications protocol:
p sends a bit by creating a file called 0 or 1, then a second file called send
p waits until send is deleted before repeating to send another bit
q waits until file send exists, then looks for file 0 or 1; whichever exists is the bit
q then deletes 0, 1, and send and waits until send is recreated before repeating to read another bit
Covert Channel
A path of communication not designed to be used for communication In example, file system is a (storage) covert channel
November 1, 2004
Slide #1-565
Rule of Transitive Confinement

If p is confined to prevent leaking, and it invokes q, then q must be similarly confined to prevent leaking Rule: if a confined process invokes a second process, the second process must be as confined as the first
November 1, 2004
Slide #1-566
Lipners Notes
All processes can obtain rough idea of time
Read system clock or wall clock time Determine number of instructions executed
All processes can manipulate time

Wait some interval of wall clock time Execute a set number of instructions, then block
November 1, 2004
Slide #1-567
Kochers Attack
This computes x = az mod n, where z = z0 zk1
x := 1; a tmp := a; fo ri: = 0 to k1 do beg in i fz i = 1 then x := ( x*a t mp) mod n; atmp := (a t mp * atmp) mod n; end resu l t:= x ;
Length of run time related to number of 1 bits in z

Isolation
Virtual machines
Emulate computer Process cannot access underlying computer system, anything not part of that computer system
Sandboxing
Does not emulate computer Alters interface between computer, process
Virtual Machine (VM)

A program that simulates hardware of computer system Virtual machine monitor (VMM) provides VM on which conventional OS can run
Each VM is one subject; VMM knows nothing about processes running on each VM VMM mediates all interactions of VM with resources, other VMS Satisfies rule of transitive closure
Example: KVM/370
Security-enhanced version of IBM VM/370 VMM Goals
Provide virtual machines for users Prevent VMs of different security classes from communicating
Provides minidisks; some VMs could share some areas of disk

Security policy controlled access to shared areas to limit communications to those allowed by policy
DEC VAX VMM

VMM is security kernel
Can run Ultrix OS or VMS OS
Invoked on trap to execute privileged instruction

Only VMM can access hardware directly VM kernel, executive levels both mapped into physical executive level
VMM subjects: users, VMs

Each VM has own disk areas, file systems Each subject, object has multilevel security, integrity labels
Sandbox
Environment in which actions of process are restricted according to security policy
Can add extra security-checking mechanisms to libraries, kernel
Program to be executed is not altered
Can modify program or process to be executed

Similar to debuggers, profilers that add breakpoints Add code to do extra checks (memory access, etc.) as program runs (software fault isolation)
Example: Limiting Execution

Sidewinder
Uses type enforcement to confine processes Sandbox built into kernel; site cannot alter it
Java VM
Restricts set of files that applet can access and hosts to which applet can connect
DTE, type enforcement mechanism for DTEL

Kernel modifications enable system administrators to configure sandboxes
November 1, 2004
Slide #1-574
Example: Trapping System Calls

Janus: execution environment
Users restrict objects, modes of access
Two components
Framework does run-time checking Modules determine which accesses allowed
Configuration file controls modules loaded, constraints to be enforced

Janus Configuration File

# bas ic modu le bas ic Load basic module # de f ine subprocess env i ronment var i ab les putenv IFS= \ t \nPATH=/sb in : /b in : /usr /b in TZ=PST8PDT Define environmental variables for process # deny access to every th ing except f i l es under /us r path deny read ,wr i t e* path a l low read,wri te /us r / * Deny all file accesses except to those under /usr #a l low subprocess to read f i l es in l ibra ry d i recto r ies # needed fo r dynamic load i ng path a l low read / l i b/* /us r / l i b/* /us r / loca l / l ib / * Allow reading of files in these directories (all dynamic load libraries are here) # needed so ch i ld can execute p rograms path a l low read,exec /sb in / * /b in / */us r /b in / * Allow reading, execution of subprograms in these directories November 1, 2004 Introduction to Computer Security 2004 Matt Bishop Slide #1-576
Janus Implementation
System calls to be monitored defined in modules On system call, Janus framework invoked
Validates system call with those specific parameters are allowed If not, sets process environment to indicate call failed If okay, framework gives control back to process; on return, framework invoked to update state
Example: reading MIME mail

Embed delete file in Postscript attachment Set Janus to disallow Postscript engine access to files
Covert Channels
Channel using shared resources as a communication path Covert storage channel uses attribute of shared resource Covert timing channel uses temporal or ordering relationship among accesses to shared resource
Example: File Manipulation

Communications protocol:
p sends a bit by creating a file called 0 or 1, then a second file called send
p waits until send is deleted before repeating to send another bit
q waits until file send exists, then looks for file 0 or 1; whichever exists is the bit
q then deletes 0, 1, and send and waits until send is recreated before repeating to read another bit
Covert storage channel: resource is directory, names of files in directory

Example: Real-Time Clock

KVM/370 had covert timing channel
VM1 wants to send 1 bit to VM2 To send 0 bit: VM1 relinquishes CPU as soon as it gets CPU To send 1 bit: VM1 uses CPU for full quantum VM2 determines which bit is sent by seeing how quickly it gets CPU Shared resource is CPU, timing because real-time clock used to measure intervaps between accesses
Example: Ordering of Events

Two VMs
Share cylinders 100200 on a disk One is High, one is Low; process on High VM wants to send to process on Low VM
Disk scheduler uses SCAN algorithm Low process seeks to cylinder 150 and relinquishes CPU
Now we know where the disk head is
Example (cont)
High wants to send a bit
To send 1 bit, High seeks to cylinder 140 and relinquish CPU To send 0 bit, High seeks to cylinder 160 and relinquish CPU
Low issues requests for tracks 139 and 161

Seek to 139 first indicates a 1 bit Seek to 161 first indicates a 0 bit
Covert timing channel: uses ordering relationship among accesses to transmit information
Noise
Noiseless covert channel uses shared resource available to sender, receiver only Noisy covert channel uses shared resource available to sender, receive, and others
Need to minimize interference enough so that message can be read in spite of others use of channel
Key Properties
Existence
Determining whether the covert channel exists
Bandwidth
Determining how much information can be sent over the channel
November 1, 2004
Slide #1-584
Detection
Covert channels require sharing Manner of sharing controls which subjects can send, which subjects can receive information using that shared resource Porras, Kemmerer: model flow of information through shared resources with a tree
Called covert flow trees
Goal Symbol Tree Nodes

Modification: attribute modified Recognition: attribute modification detected Direct recognition: subject can detect attribute modification by referencing attribute directly or calling function that returns it Inferred recognition: subject can detect attribute modification without direct reference Inferred-via: info passed from one attribute to another via specified primitive (e.g. syscall) Recognized-new-state: modified attribute specified by inferred-via goal
Other Tree Nodes

Operation symbol represents primitive operation Failure symbol indicates information cannot be sent along path And symbol reached when for all children
Child is operation; and If child goal, then goal is reached
Or symbol reached when for any child:

Child is operation; or If child goal, then goal is reached
Constructing Tree
Example: files in file system have 3 attributes
locked: true when file locked isopen: true when file opened inuse: set containing PID of processes having file open
Functions:
read_access(p, f): true if p has read rights over file f empty(s): true if set s is empty random: returns one of its arguments chosen at random
Locking and Opening Routines

( *lock the f i l ei fi ti s notlocked and not opened; otherw ise i nd ica te i ti sl ocked by r eturn ing fa l se * ) procedure Lock f i le ( f :f i l e ) : boo lean; beg in i f no tf . locked and empty ( f . inuse) then f . locked := t rue ; end; ( * un lock the f i le * ) procedure Unlock f i le ( f :f i l e ) ; beg in i ff . locked t hen f . locked := fa lse ; end; ( * say whether the f i le i slocked * ) ion F i l e locked( f :f i l e ) : boo lean; func t beg in Fi le locked : =f . locked; end; ( * open the f i l ei fi ti sn tl ocked and the process has the r igh t to read the f i l e* ) procedure Openf i le ( f :f i l e ) ; beg in i f no tf . locked and read_access(process_ id ,f )then ( * add process ID to inuse se t* ) f . inuse = f . i nuse + process_ id ; end; ( *i fthe process can read the f i l e ,say i fthe f i l e is open, o therwise re turn a va lue a t random * ) func t ion F i l eopened( f :f i l e ) : boo lean; beg in i f no t read_access(process_ id ,f )t hen Fi leopened := random( t rue , fa lse); e lse Fi leopened := no ti sempty( f . inuse) ; end
November 1, 2004
Slide #1-589
Attributes and Operations

Lockfile reference modify return locked, inuse locked Unlockfile Filelocked Openfile locked locked locked locked, inuse inuse Fileopened inuse inuse
means no attribute affected in specified manner
November 1, 2004
Slide #1-590
Tree Construction
This is for attribute locked
Goal state: covert storage channel via attribute locked Type of goal controls construction
And node has 2 children, a modification and a recognition

Here, both of attribute locked
First Step
Covert storage channel via attribute locked Modification of attribute locked Recognition of attribute locked
Put and node under goal Put children under and node
November 1, 2004
Slide #1-592
Second Step
Modification of attribute locked +
Operations Lockfile and Unlockfile modify locked

See attribute and operations table
Lockfile
Unlockfile
November 1, 2004
Slide #1-593
Third Step
Recognition of attribute locked + Direct recognition of attribute locked + Indirect recognition of attribute locked + Infer attribute locked via attribute inuse
Recognition had direct, inferred recognition children Direct recognition child: and node with Filelocked child
Filelocked returns value of locked
Filelocked
Inferred recognition child: or node with inferredvia node

Infers locked from inuse
Slide #1-594
November 1, 2004
Fourth Step
Infer attribute locked via attribute inuse Openfile Recognition of attribute inuse
Inferred-via node requires Openfile

Change in attribute inuse represented by recognize-new-state goal
November 1, 2004
Slide #1-595
Fifth Step
Recognition of attribute inuse + Direct recognition of attribute inuse + Indirect recognition of attribute inuse +
Recognize-new-state node
Direct recognition node: or child, Fileopened node beneath (recognizes change in inuse directly) Inferred recognition node: or child, FALSE node beneath (nothing recognizes change in inuse indirectly)
Fileopened
FALSE
November 1, 2004
Slide #1-596
Final Tree
November 1, 2004
Slide #1-597
Finding Covert Channels

Find sequences of operations that modify attribute
( Lockfile ), ( Unlockfile )
Find sequences of operations that recognize modifications to attribute

( Filelocked ), ( Openfile, Fileopened ) )
November 1, 2004
Slide #1-598
Covert Channel Commands

Sequences with first element from first list, second element from second list
Lockfile, then Filelocked Unlockfile, then Filelocked Lockfile, then Openfile, then Fileopened Unlockfile, then Openfile, then Fileopened
November 1, 2004
Slide #1-599
Mitigation
Goal: obscure amount of resources a process uses
Receiver cannot determine what part sender is using and what part is obfuscated
How to do this?
Devote uniform, fixed amount of resources to each process Inject randomness into allocation, use of resources
Example: Pump
communications buffer holds n items Low buffer High buffer
Low process
High process
November 1, 2004
Slide #1-601
Covert Timing Channel

High process can control rate at which pump sends it messages Initialization: Low sends messages to pump until communications buffer full
Low gets ACK for each message put into the buffer; no ACK for messages when communications buffer full
Protocol: sequence of trials; for each trial

High sends a 1 by reading a message
Then Low gets ACK when it sends another message
High sends a 0 by not reading a message

November 1, 2004
Then Low doesnt gets ACK when it sends another message

Slide #1-602
How to Fix
Assume: Low process, pump can process messages faster than High process Case 1: High process handles messages more quickly than Low process gets acknowledgements
Pump artificially delaying ACKs
Low process waits for ACK regardless of whether buffer is full
Low cannot tell whether buffer is full

Closes covert channel
Not optimal (processes may wait even when unnecessary)

How to Fix (cont)

Case 2: Low process sends messages faster than High process can remove them
Maximizes performance Opens covert channel
Case 3: Pump, processes handle messages at same rate

Decreases bandwidth of covert channel, increases performance Opens covert channel, sub-optimal performance
Adding Noise to Direct Channel

Kang, Moskowitz: do this in such a way as to approximate case 3
Reduces covert channels capacity to 1/nr
r time between Low process sending message and receiving ACK when buffer not full
Conclusion: pump substantially reduces capacity of covert channel between High, Low processes when compared with direct connection
Key Points
Confinement problem: prevent leakage of information
Solution: separation and/or isolation
Shared resources offer paths along which information can be transferred Covert channels difficult if not impossible to eliminate
Bandwidth can be greatly reduced, however!
Chapter 17: Introduction to Assurance

Overview Why assurance? Trust and assurance Life cycle and assurance Building security in vs. adding security later
November 1, 2004
Slide #1-607
Overview
Trust Problems from lack of assurance Types of assurance Life cycle and assurance Waterfall life cycle model Other life cycle models Adding security afterwards
November 1, 2004
Trust
Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements Trust is a measure of trustworthiness relying on the evidence Assurance is confidence that an entity meets its security requirements based on evidence provided by applying assurance techniques
Relationships
Policy Statement of requirements that explicitly defines the security expectations of the mechanism(s) Provides justification that the mechanism meets policy through assurance evidence and approvals based on evidence Executable entities that are designed and implemented to meet the requirements of the policy
Assurance Mechanisms
November 1, 2004
Slide #1-610
Problem Sources
1. 2. 3. 4. 5. 6. 7. 8. 9. Requirements definitions, omissions, and mistakes System design flaws Hardware implementation flaws, such as wiring and chip flaws Software implementation errors, program bugs, and compiler bugs System use and operation errors and inadvertent mistakes Willful system misuse Hardware, communication, or other equipment malfunction Environmental problems, natural causes, and acts of God Evolution, maintenance, faulty upgrades, and decommissions
November 1, 2004
Slide #1-611
Examples
Challenger explosion
Sensors removed from booster rockets to meet accelerated launch schedule
Deaths from faulty radiation therapy system

Hardware safety interlock removed Flaws in software design
Bell V22 Osprey crashes

Failure to correct for malfunctioning components; two faulty ones could outvote a third
Intel 486 chip

Bug in trigonometric functions
Role of Requirements
Requirements are statements of goals that must be met
Vary from high-level, generic issues to lowlevel, concrete issues
Security objectives are high-level security issues Security requirements are specific, concrete issues
Types of Assurance
Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound Design assurance is evidence establishing design sufficient to meet requirements of security policy Implementation assurance is evidence establishing implementation consistent with security requirements of security policy
Types of Assurance
Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation
Also called administrative assurance
November 1, 2004
Slide #1-615
Life Cycle
Security requirements 2 Assurance justification 4 1 3 Design and implementation refinement
Design
Implementation
November 1, 2004
Slide #1-616
Life Cycle
Conception Manufacture Deployment Fielded Product Life
November 1, 2004
Slide #1-617
Conception
Idea
Decisions to pursue it
Proof of concept
See if idea has merit
High-level requirements analysis

What does secure mean for this concept? Is it possible for this concept to meet this meaning of security? Is the organization willing to support the additional resources required to make this concept meet this meaning of security?
November 1, 2004
Slide #1-618
Manufacture
Develop detailed plans for each group involved
May depend on use; internal product requires no sales
Implement the plans to create entity

Includes decisions whether to proceed, for example due to market needs
Deployment
Delivery
Assure that correct masters are delivered to production and protected Distribute to customers, sales organizations
Installation and configuration

Ensure product works appropriately for specific environment into which it is installed Service people know security procedures
Fielded Product Life

Routine maintenance, patching
Responsibility of engineering in small organizations Responsibility may be in different group than one that manufactures product
Customer service, support organizations Retirement or decommission of product

Waterfall Life Cycle Model

Requirements definition and analysis
Functional and non-functional General (for customer), specifications
System and software design Implementation and unit testing Integration and system testing Operation and maintenance
November 1, 2004
Relationship of Stages
Requirements definition and analysis
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
November 1, 2004
Slide #1-623
Models
Exploratory programming
Develop working system quickly Used when detailed requirements specification cannot be formulated in advance, and adequacy is goal No requirements or design specification, so low assurance
Prototyping
Objective is to establish system requirements Future iterations (after first) allow assurance techniques
Models
Formal transformation
Create formal specification Translate it into program using correctness-preserving transformations Very conducive to assurance methods
System assembly from reusable components

Depends on whether components are trusted Must assure connections, composition as well Very complex, difficult to assure
Models
Extreme programming
Rapid prototyping and best practices Project driven by business decisions Requirements open until project complete Programmers work in teams Components tested, integrated several times a day Objective is to get system into production as quickly as possible, then enhance it Evidence adduced after development needed for assurance
Security: Built In or Add On?

Think of security as you do performance
You dont build a system, then add in performance later
Can tweak system to improve performance a little Much more effective to change fundamental algorithms, design
You need to design it in

Otherwise, system lacks fundamental and structural concepts for high assurance
Reference Validation Mechanism

Reference monitor is access control concept of an abstract machine that mediates all accesses to objects by subjects Reference validation mechanism (RVM) is an implementation of the reference monitor concept.
Tamperproof Complete (always invoked and can never be bypassed) Simple (small enough to be subject to analysis and testing, the completeness of which can be assured)
Last engenders trust by providing assurance of correctness
Examples
Security kernel combines hardware and software to implement reference monitor Trusted computing base (TCB) is all protection mechanisms within a system responsible for enforcing security policy
Includes hardware and software Generalizes notion of security kernel
Adding On Security
Key to problem: analysis and testing Designing in mechanisms allow assurance at all levels
Too many features adds complexity, complicates analysis
Adding in mechanisms makes assurance hard

Gap in abstraction from requirements to design may prevent complete requirements testing May be spread throughout system (analysis hard) Assurance may be limited to test results
Example
2 AT&T products
Add mandatory controls to UNIX system SV/MLS
Add MAC to UNIX System V Release 3.2
SVR4.1ES
Re-architect UNIX system to support MAC
November 1, 2004
Slide #1-631
Comparison
Architecting of System
SV/MLS: used existing kernel modular structure; no implementation of least privilege SVR4.1ES: restructured kernel to make it highly modular and incorporated least privilege
November 1, 2004
Slide #1-632
Comparison
File Attributes (inodes)
SV/MLS added separate table for MAC labels, DAC permissions
UNIX inodes have no space for labels; pointer to table added Problem: 2 accesses needed to check permissions Problem: possible inconsistency when permissions changed Corrupted table causes corrupted permissions
SVR4.1ES defined new inode structure

Included MAC labels Only 1 access needed to check permissions
November 1, 2004
Slide #1-633
Key Points
Assurance critical for determining trustworthiness of systems Different levels of assurance, from informal evidence to rigorous mathematical evidence Assurance needed at all stages of system life cycle Building security in is more effective than adding it later
November 1, 2004
Slide #1-634
Chapter 18: Evaluating Systems

Goals Trusted Computer System Evaluation Criteria FIPS 140 Common Criteria SSE-CMM
Overview
Goals
Why evaluate?
Evaluation criteria
TCSEC (aka Orange Book) FIPS 140 Common Criteria SSE-CMM
November 1, 2004
Goals
Show that a system meets specific security requirements under specific conditions
Called a trusted system Based on specific assurance evidence
Formal evaluation methodology

Technique used to provide measurements of trust based on specific security requirements and evidence of assurance
Evaluation Methodology
Provides set of requirements defining security functionality for system Provides set of assurance requirements delineating steps for establishing that system meets its functional requirements Provides methodology for determining that system meets functional requirements based on analysis of assurance evidence Provides measure of result indicating how trustworthy system is with respect to security functional requirements
Called level of trust
Why Evaluate?
Provides an independent assessment, and measure of assurance, by experts
Includes assessment of requirements to see if they are consistent, complete, technically sound, sufficient to counter threats Includes assessment of administrative, user, installation, other documentation that provides information on proper configuration, administration, use of system
Independence critical
Experts bring fresh perspectives, eyes to assessment
Bit of History
Government, military drove early evaluation processes
Their desire to use commercial products led to businesses developing methodologies for evaluating security, trustworthiness of systems
Methodologies provide combination of

Functional requirements Assurance requirements Levels of trust
TCSEC: 19831999
Trusted Computer System Evaluation Criteria
Also known as the Orange Book Series that expanded on Orange Book in specific areas was called Rainbow Series Developed by National Computer Security Center, US Dept. of Defense
Heavily influenced by Bell-LaPadula model and reference monitor concept Emphasizes confidentiality
Integrity addressed by *-property
Functional Requirements
Discretionary access control requirements
Control sharing of named objects Address propagation of access rights, ACLs, granularity of controls
Object reuse requirements

Hinder attacker gathering information from disk or memory that has been deleted Address overwriting data, revoking access rights, and assignment of resources when data in resource from previous use is present
Mandatory access control requirements (B1 up)
Simple security condition, *-property Description of hierarchy of labels
Label requirements (B1 up)

Used to enforce MAC Address representation of classifications, clearances, exporting labeled information, human-readable output
Identification, authentication requirements

Address granularity of authentication data, protecting that data, associating identity with auditable actions
Audit requirements
Define what audit records contain, events to be recorded; set increases as other requirements increase
Trusted path requirements (B2 up)

Communications path guaranteed between user, TCB
System architecture requirements

Tamperproof reference validation mechanism Process isolation Enforcement of principle of least privilege Well-defined user interfaces
November 1, 2004
Trusted facility management (B2 up)
Separation of operator, administrator roles
Trusted recovery (A1)

Securely recover after failure or discontinuity
System integrity requirement

Hardware diagnostics to validate on-site hardware, firmware of TCB
Assurance Requirements
Configuration management requirements (B2 up)
Identify configuration items, consistent mappings among documentation and code, tools for generating TCB
System architecture requirements

Modularity, minimize complexity, etc. TCB full reference validation mechanism at B3
Trusted distribution requirement (A1)

Address integrity of mapping between masters and onsite versions Address acceptance procedures
November 1, 2004
Slide #1-646
Design specification, verification requirements
B1: informal security policy model shown to be consistent with its axioms B2: formal security policy model proven to be consistent with its axioms, descriptive top-level specification (DTLS) B3: DTLS shown to be consistent with security policy model A1: formal top-level specification (FTLS) shown consistent with security policy model using approved formal methods; mapping between FTLS, source code
Testing requirements
Address conformance with claims, resistance to penetration, correction of flaws Requires searching for covert channels for some classes
Product documentation requirements

Security Features Users Guide describes uses, interactions of protection mechanisms Trusted Facility Manual describes requirements for running system securely
Other documentation: test, design docs

Evaluation Classes A and B

A1 Verified protection; significant use of formal methods; trusted distribution; code, FTLS correspondence B3 Security domains; full reference validation mechanism; increases trusted path requirements, constrains code development; more DTLS requirements; documentation B2 Structured protection; formal security policy model; MAC for all objects, labeling; trusted path; least privilege; covert channel analysis, configuration management B1 Labeled security protection; informal security policy model; MAC for some objects; labeling; more stringent security testing
Evaluation Classes C and D

C2 Controlled access protection; object reuse, auditing, more stringent security testing C1 Discretionary protection; minimal functional, assurance requirements; I&A controls; DAC D Did not meet requirements of any other class
November 1, 2004
Slide #1-650
Evaluation Process
Run by government, no fee to vendor 3 stages
Application: request for evaluation
May be denied if govt didnt need product
Preliminary technical review

Discussion of evaluation process, schedules, development process, technical content, etc. Determined schedule for evaluation
Evaluation phase
Evaluation Phase
3 parts; results of each presented to technical review board composed of senior evaluators not on evaluating team; must approve that part before moving on to next part
Design analysis: review design based on documentation provided; developed initial product assessment report
Source code not reviewed
Test analysis: vendors, evaluators tests Final evaluation report
Once approved, all items closed, rating given

RAMP
Ratings Maintenance Program goal: maintain assurance for new version of evaluated product Vendor would update assurance evidence Technical review board reviewed vendors report and, on approval, assigned evaluation rating to new version of product Note: major changes (structural, addition of some new functions) could be rejected here and a full new evaluation required
Impact
New approach to evaluating security
Based on analyzing design, implementation, documentation, procedures Introduced evaluation classes, assurance requirements, assurance-based evaluation High technical standards for evaluation Technical depth in evaluation procedures
Some problems
Evaluation process difficult, lacking in resources Mixed assurance, functionality together Evaluations only recognized in US
November 1, 2004
Slide #1-654
Scope Limitations
Written for operating systems
NCSC introduced interpretations for other things such as networks (Trusted Network Interpretation, the Red Book), databases (Trusted Database Interpretation, the Purple or Lavender Book)
Focuses on needs of US government

Most commercial firms do not need MAC
Does not address integrity or availability

Critical to commercial firms
Process Limitations
Criteria creep (expansion of requirements defining classes)
Criteria interpreted for specific product types Sometimes strengthened basic requirements over time Good for community (learned more about security), but inconsistent over time
Length of time of evaluation

Misunderstanding depth of evaluation Management practices of evaluation As was free, sometimes lacking in motivation
Contributions
Heightened awareness in commercial sector to computer security needs Commercial firms could not use it for their products
Did not cover networks, applications Led to wave of new approaches to evaluation Some commercial firms began offering certifications
Basis for several other schemes, such as Federal Criteria, Common Criteria
FIPS 140: 1994Present

Evaluation standard for cryptographic modules (implementing cryptographic logic or processes)
Established by US government agencies and Canadian Security Establishment
Updated in 2001 to address changes in process and technology

Officially, FIPS 140-2
Evaluates only crypto modules

If software, processor executing it also included, as is operating system
Requirements
Four increasing levels of security FIPS 140-1 covers basic design, documentation, roles, cryptographic key management, testing, physical security (from electromagnetic interference), etc. FIPS 140-2 covers specification, ports & interfaces; finite state model; physical security; mitigation of other attacks; etc.
Security Level 1
Encryption algorithm must be FIPSapproved algorithm Software, firmware components may be executed on general-purpose system using unevaluated OS No physical security beyond use of production-grade equipment required
Security Level 2
More physical security
Tamper-proof coatings or seals or pick-resistent locks
Role-based authentication
Module must authenticate that operator is authorized to assume specific role and perform specific services
Software, firmware components may be executed on multiuser system with OS evaluated at EAL2 or better under Common Criteria
Must use one of specified set of protection profiles
Security Level 3
Enhanced physical security
Enough to prevent intruders from accessing critical security parameters within module
Identity-based authentication Strong requirements for reading, altering critical security parameters Software, firmware components require OS to have EAL3 evaluation, trusted path, informal security policy model
Can use equivalent evaluated trusted OS instead
Security Level 4
Envelope of protection around module that detects, responds to all unauthorized attempts at physical access
Includes protection against environmental conditions or fluctuations outside modules range of voltage, temperatures
Software, firmware components require OS meet functional requirements for Security Level 3, and assurance requirements for EAL4
Equivalent trusted operating system may be used
Impact
By 2002, 164 modules, 332 algorithms tested
About 50% of modules had security flaws More than 95% of modules had documentation errors About 25% of algorithms had security flaws More than 65% had documentation errors
Program greatly improved quality, security of cryptographic modules
November 1, 2004
Slide #1-664
Common Criteria: 1998Present

Began in 1998 with signing of Common Criteria Recognition Agreement with 5 signers
US, UK, Canada, France, Germany
As of May 2002, 10 more signers

Australia, Finland, Greece, Israel, Italy, Netherlands, New Zealand, Norway, Spain, Sweden; India, Japan, Russia, South Korea developing appropriate schemes
Standard 15408 of International Standards Organization De facto US security evaluation standard

Evaluation Methodology
CC documents
Overview of methodology, functional requirements, assurance requirements
CC Evaluation Methodology (CEM)

Detailed guidelines for evaluation at each EAL; currently only EAL1EAL4 defined
Evaluation Scheme or National Scheme

Country-specific infrastructures implementing CEM In US, its CC Evaluation and Validation Scheme; NIST accredits commercial labs to do evaluations
CC Terms
Target of Evaluation (TOE): system or product being evaluated TOE Security Policy (TSP): set of rules regulating how assets managed, protected, distributed within TOE TOE Security Functions (TSF): set consisting of all hardware, software, firmware of TOE that must be relied on for correct enforcement of TSP
Generalization of TCB
Protection Profiles
CC Protection Profile (PP): implementationindependent set of security requirements for category of products or systems meeting specific consumer needs
Includes functional requirements
Chosen from CC functional requirements by PP author
Includes assurance requirements

Chosen from CC assurance requirements; may be EAL plus others
PPs for firewalls, desktop systems, etc. Evolved from ideas in earlier criteria
Form of PP
1. Introduction
PP Identification and PP Overview
2. Product or System Family Description

Includes description of type, general features of product or system
3. Product or System Family Security Environment

Assumptions about intended use, environment of use; Threats to the assets; and Organizational security policies for product or system
Form of PP (cont)
4. Security Objectives
Trace security objectives for product back to aspects of identified threats and/or policies Trace security objectives for environment back to threats not completely countered by product or systemand/or policies or assumptions not completely met by product or system
5. IT Security Requirements
Security functional requirements drawn from CC Security assurance requirements based on an EAL
November 1, 2004
May supply other requirements without reference to CC

Form of PP (cont)
6. Rationale
Security Objectives Rationale demonstrates stated objectives traceable to all assumptions, threats, policies Security Requirements Rationale demonstrates requirements for product or system and for environment traceable to objectives and meet them This section provides assurance evidence that PP is complete, consistent, technically sound
November 1, 2004
Slide #1-671
Security Target
CC Security Target (ST): set of security requirements and specifications to be used as basis for evaluation of identified product or system
Can be derived from a PP, or directly from CC
If from PP, ST can reference PP directly
Addresses issues for specific product or system

PP addresses issues for a family of potential products or systems
How It Works
Find appropriate PP and develop appropriate ST based upon it
If no PP, use CC to develop ST directly
Evaluate ST in accordance with assurance class ASE

Validates that ST is complete, consistent, technically sound
Evaluate product or system against ST

Form of ST
1. Introduction
ST Identification, ST Overview CC Conformance Claim
Part 2 (or part 3) conformant if all functional requirements are from part 2 (or part 3) of CC Part 2 (or part 3) extended if uses extended requirements defined by vendor as well
2. Product or System Description

Describes TOE as aid to understanding its security requirement
Form of ST (cont)
3.Product or System Family Security Environment 4.Security Objectives 5.IT Security Requirements
These are the same as for a PP
November 1, 2004
Slide #1-675
Form of ST (cont)
6. Product or System Summary Specification
Statement of security functions, description of how these meet functional requirements Statement of assurance measures specifying how assurance requirements met
7. PP Claims
Claims of conformance to (one or more) PP requirements
Form of ST (cont)
8. Rationale
Security objectives rationale demonstrates stated objectives traceable to assumptions, threats, policies Security requirements rationale demonstrates requirements for TOE and environment traceable to objectives and meets them TOE summary specification rationale demonstrates how TOE security functions and assurance measures meet security requirements Rationale for not meeting all dependencies PP claims rationale explains differences between the ST objectives and requirements and those of any PP to which conformance is claimed
CC Requirements
Both functional and assurance requirements EALs built from assurance requirements Requirements divided into classes based on common purpose Classes broken into smaller groups (families) Families composed of components, or sets of definitions of detailed requirements, dependent requirements and definition of hierarchy of requirements
Security Functional Requirements
November 1, 2004
Slide #1-679
SSE-CMM: 1997Present
Based on Software Engineering Capability Maturity Model (SE-CMM or just CMM) Defines requirements for process of developing secure systems, not for systems themselves
Provides maturity levels, not levels of trust Used to evaluate an organizations security engineering
SSE-CMM Model
Process capability: range of expected results that can be achieved by following process
Predictor of future project outcomes
Process performance: measure of actual results Process maturity: extent to which a process explicitly defined, managed, measured, controlled, and is effective Divides process into 11 areas, and 11 more for project and organizational practices
Each process area contains a goal, set of base processes
Process Areas
Process areas:
Administer security controls Assess impact, security risk, threat, vulnerability Build assurance argument Coordinate security Monitor system security posture Provide security input Specify security needs Verify, validate security
November 1, 2004
Practices:
Ensure quality Manage configuration, project risk Monitor, control technical effort Plan technical effort Define, improve organizations systems engineering process Manage product line evolution Provide ongoing skills, knowledge Coordinate with suppliers
Slide #1-682
Example: Assess Threat

Goal: threats to the security of the system will be identified and characterized Base processes:
Identify natural, man-made threats Identify threat units of measure Assess threat agent capability, threat likelihood Monitor threats and their characteristics
November 1, 2004
Capability Maturity Levels

Performed informally: perform base processes Planned and tracked: address project-level definition, planning, performance, verification issues Well-defined: focus on defining, refining standard practice and coordinating it across organization Quantitatively controlled: focus on establishing measurable quality goals, objectively managing their performance Continuously improving: improve organizational capability, process effectiveness
Using the SSE-CMM

Begin with process area
Identify area goals, base processes If all processes present, determine how mature base processes are
Assess them against capability maturity levels May require interacting with those who use the base processes
Do this for each process area

Level of maturity for area is lowest level of the base processes for that area Tabular representation (called Rating Profile) helps communicate results
Key Points
First public, widely used evaluation methodology was TCSEC (Orange Book)
Criticisms led to research and development of other methodologies
Evolved into Common Criteria Other methodologies used for special environments
Chapter 19: Malicious Logic

What is malicious logic Types of malicious logic Defenses
November 1, 2004
Slide #1-687
Overview
Defining malicious logic Types
Trojan horses Computer viruses and worms Other types
Defenses
Properties of malicious logic Trust
Malicious Logic
Set of instructions that cause site security policy to be violated
November 1, 2004
Slide #1-689
Example
Shell script on a UNIX system:
cp /b i n/sh / tmp/ . xyzzy chmod u+s,o+x / tmp/ . xyzzy rm . / l s l s $*
Place in program called ls and trick someone into executing it You now have a setuid-to-them shell!
Trojan Horse
Program with an overt purpose (known to user) and a covert purpose (unknown to user)
Often called a Trojan Named by Dan Edwards in Anderson Report
Example: previous script is Trojan horse

Overt purpose: list files in directory Covert purpose: create setuid shell
Example: NetBus
Designed for Windows NT system Victim uploads and installs this
Usually disguised as a game program, or in one
Acts as a server, accepting and executing commands for remote administrator

This includes intercepting keystrokes and mouse motions and sending them to attacker Also allows attacker to upload, download files
Replicating Trojan Horse

Trojan horse that makes copies of itself
Also called propagating Trojan horse Early version of animal game used this to delete copies of itself
Hard to detect
1976: Karger and Schell suggested modifying compiler to include Trojan horse that copied itself into specific programs including later version of the compiler 1980s: Thompson implements this
Thompson's Compiler
Modify the compiler so that when it compiles login , login accepts the user's correct password or a fixed password (the same one for all users) Then modify the compiler again, so when it compiles a new version of the compiler, the extra code to do the first step is automatically inserted Recompile the compiler Delete the source containing the modification and put the undoctored source back
The Login Program

user password login source
correct compiler
login executable
logged in user password or magic password login source

doctored compiler
login executable
logged in
The Compiler
login source compiler source
correct compiler
compiler executable correct login executable
login source
compiler source
doctored compiler
compiler executable
rigged login executable

Comments
Great pains taken to ensure second version of compiler never released
Finally deleted when a new compiler executable from a different system overwrote the doctored compiler
The point: no amount of source-level verification or scrutiny will protect you from using untrusted code
Also: having source code helps, but does not ensure youre safe
Computer Virus
Program that inserts itself into one or more files and performs some action
Insertion phase is inserting itself into file Execution phase is performing some (possibly null) action
Insertion phase must be present

Need not always be executed Lehigh virus inserted itself into boot file only if boot file not infected
Pseudocode
beg inv i rus : i f sp read-cond i t ion then beg in fo r some se to f ta rge tf i l es do beg in i fta rge ti s no ti nfec ted then beg in determine where to p l ace v i r us ins t r uct ions copy ins t ruc t ions f rom beg invi rusto endv i rus i n to ta r get a l te r ta r get to execute added i nst ruc t i ons end; end; end; per fo r m some ac t ion(s) goto beg inn ing o fin fec ted program endv i rus :
Trojan Horse Or Not?

Yes
Overt action = infected programs actions Covert action = virus actions (infect, execute)
No
Overt purpose = virus actions (infect, execute) Covert purpose = none
Semantic, philosophical differences

Defenses against Trojan horse also inhibit computer viruses
History
Programmers for Apple II wrote some
Not called viruses; very experimental
Fred Cohen
Graduate student who described them Teacher (Adleman) named it computer virus Tested idea on UNIX systems and UNIVAC 1108 system
Cohens Experiments
UNIX systems: goal was to get superuser privileges
Max time 60m, min time 5m, average 30m Virus small, so no degrading of response time Virus tagged, so it could be removed quickly
UNIVAC 1108 system: goal was to spread

Implemented simple security property of Bell-LaPadula As writing not inhibited (no *-property enforcement), viruses spread easily
First Reports
Brain (Pakistani) virus (1986)
Written for IBM PCs Alters boot sectors of floppies, spreads to other floppies
MacMag Peace virus (1987)

Written for Macintosh Prints universal message of peace on March 2, 1988 and deletes itself
More Reports
Duffs experiments (1987)
Small virus placed on UNIX system, spread to 46 systems in 8 days Wrote a Bourne shell script virus
Highlands Lotus 1-2-3 virus (1989)

Stored as a set of commands in a spreadsheet and loaded when spreadsheet opened Changed a value in a specific row, column and spread to other files
Types of Viruses
Boot sector infectors Executable infectors Multipartite viruses TSR viruses Stealth viruses Encrypted viruses Polymorphic viruses Macro viruses
November 1, 2004
Boot Sector Infectors

A virus that inserts itself into the boot sector of a disk
Section of disk containing code Executed when system first sees the disk
Including at boot time
Example: Brain virus

Moves disk interrupt vector from 13H to 6DH Sets new interrupt vector to invoke Brain virus When new floppy seen, check for 1234H at location 4
If not there, copies itself onto disk after saving original boot block
Executable Infectors
Header 0 Header 0 100 Virus code 100 200 Executable code and data First program instruction to be e xecuted 1000 Executable code and data 1000 1100
A virus that infects executable programs

Can infect either .EXE or .COM on PCs May prepend itself (as shown) or put itself anywhere, fixing up binary so it is executed at some point
Executable Infectors (cont)

Jerusalem (Israeli) virus
Checks if system infected
If not, set up to respond to requests to execute files
Checks date
If not 1987 or Friday 13th, set up to respond to clock interrupts and then run program Otherwise, set destructive flag; will delete, not infect, files
Then: check all calls asking files to be executed

Do nothing for COMND.COM Otherwise, infect or delete
Error: doesnt set signature when .EXE executes

So .EXE files continually reinfected
Multipartite Viruses
A virus that can infect either boot sectors or executables Typically, two parts
One part boot sector infector Other part executable infector
November 1, 2004
Slide #1-709
TSR Viruses
A virus that stays active in memory after the application (or bootstrapping, or disk mounting) is completed
TSR is Terminate and Stay Resident
Examples: Brain, Jerusalem viruses

Stay in memory after program or disk mount is completed
Stealth Viruses
A virus that conceals infection of files Example: IDF virus modifies DOS service interrupt handler as follows:
Request for file length: return length of uninfected file Request to open file: temporarily disinfect file, and reinfect on closing Request to load file for execution: load infected file
Encrypted Viruses
A virus that is enciphered except for a small deciphering routine
Detecting virus by signature now much harder as most of virus is enciphered
Deciphering routine
Virus code
Enciphered virus code Deciphering key
November 1, 2004
Slide #1-712
Example
( * Decrypt ion code o f the 1260 v i rus * ) ( *in i t ia l i ze the reg is te r sw i th t he keys * ) rA = k1;rB = k2; ( *in i t ia l i ze rC wi th the v i rus ; s ta r ts a t sov , ends at eov * ) rC = sov ; ( *the enc iphermentloop * ) whi le ( r C != eov) do beg in ( * enc ipher the byte o f the message * ) ( * rC) = ( * rC) xor rA xor rB ; ( * advance a l lthe counters * ) rC = rC + 1 ; rA = rA + 1 ; end
Polymorphic Viruses
A virus that changes its form each time it inserts itself into another program Idea is to prevent signature detection by changing the signature or instructions used for deciphering routine At instruction level: substitute instructions At algorithm level: different algorithms to achieve the same purpose Toolkits to make these exist (Mutation Engine, Trident Polymorphic Engine)
Example
These are different instructions (with different bit patterns) but have the same effect:
add 0 to register subtract 0 from register xor 0 with register no-op
Polymorphic virus would pick randomly from among these instructions

Macro Viruses
A virus composed of a sequence of instructions that are interpreted rather than executed directly Can infect either executables (Duffs shell virus) or data files (Highlands Lotus 1-2-3 spreadsheet virus) Independent of machine architecture
But their effects may be machine dependent
Example
Melissa
Infected Microsoft Word 97 and Word 98 documents
Windows and Macintosh systems
Invoked when program opens infected file Installs itself as open macro and copies itself into Normal template
This way, infects any files that are opened in future
Invokes mail program, sends itself to everyone in users address book

Computer Worms
A program that copies itself from one computer to another Origins: distributed computations
Schoch and Hupp: animations, broadcast messages Segment: part of program copied onto workstation Segment processes data, communicates with worms controller Any activity on workstation caused segment to shut down
Example: Internet Worm of 1988

Targeted Berkeley, Sun UNIX systems
Used virus-like attack to inject instructions into running program and run them To recover, had to disconnect system from Internet and reboot To prevent re-infection, several critical programs had to be patched, recompiled, and reinstalled
Analysts had to disassemble it to uncover function Disabled several thousand systems in 6 or so hours
Example: Christmas Worm

Distributed in 1987, designed for IBM networks Electronic letter instructing recipient to save it and run it as a program
Drew Christmas tree, printed Merry Christmas! Also checked address book, list of previously received email and sent copies to each address
Shut down several IBM networks Really, a macro worm

Written in a command language that was interpreted
Rabbits, Bacteria
A program that absorbs all of some class of resources Example: for UNIX system, shell commands:
whi le t rue do mkdi rx chd i rx done
Exhausts either disk space or file allocation table (inode) space

Logic Bombs
A program that performs an action that violates the site security policy when some external event occurs Example: program that deletes companys payroll records when one particular record is deleted
The particular record is usually that of the person writing the logic bomb Idea is if (when) he or she is fired, and the payroll record deleted, the company loses all those records
Defenses
Distinguish between data, instructions Limit objects accessible to processes Inhibit sharing Detect altering of files Detect actions beyond specifications Analyze statistical characteristics
November 1, 2004
Data vs. Instructions

Malicious logic is both
Virus: written to program (data); then executes (instructions)
Approach: treat data and instructions as separate types, and require certifying authority to approve conversion
Keys are assumption that certifying authority will not make mistakes and assumption that tools, supporting infrastructure used in certifying process are not corrupt
Example: LOCK
Logical Coprocessor Kernel
Designed to be certified at TCSEC A1 level
Compiled programs are type data

Sequence of specific, auditable events required to change type to executable
Cannot modify executable objects

So viruses cant insert themselves into programs (no infection phase)
Example: Duff and UNIX

Observation: users with execute permission usually have read permission, too
So files with execute permission have type executable; those without it, type data Executable files can be altered, but type immediately changed to data
Implemented by turning off execute permission Certifier can change them back
So virus can spread only if run as certifier
Limiting Accessibility
Basis: a user (unknowingly) executes malicious logic, which then executes with all that users privileges
Limiting accessibility of objects should limit spread of malicious logic and effects of its actions
Approach draws on mechanisms for confinement

Information Flow Metrics

Idea: limit distance a virus can spread Flow distance metric fd(x):
Initially, all info x has fd(x) = 0 Whenever info y is shared, fd(y) increases by 1 Whenever y1, , yn used as input to compute z, fd(z) = max(fd(y1), , fd(yn))
Information x accessible if and only if for some parameter V, fd(x) < V

Example
Anne: VA = 3; Bill, Cathy: VB = VC = 2 Anne creates program P containing virus Bill executes P
P tries to write to Bills program Q
Works, as fd(P) = 0, so fd(Q) = 1 < VB
Cathy executes Q
Q tries to write to Cathys program R
Fails, as fd(Q) = 1, so fd(R) would be 2
Problem: if Cathy executes P, R can be infected

So, does not stop spread; slows it down greatly, though
Implementation Issues
Metric associated with information, not objects
You can tag files with metric, but how do you tag the information in them? This inhibits sharing
To stop spread, make V = 0

Disallows sharing Also defeats purpose of multi-user systems, and is crippling in scientific and developmental environments
Sharing is critical here
Reducing Protection Domain

Application of principle of least privilege Basic idea: remove rights from process so it can only perform its function
Warning: if that function requires it to write, it can write anything But you can make sure it writes only to those objects you expect
Example: ACLs and C-Lists

s1 owns file f1 and s2 owns program p2 and file f3
Suppose s1 can read, write f1, execute p2, write f3 Suppose s2 can read, write, execute p2 and read f3
s1 needs to run p2
p2 contains Trojan horse
So s1 needs to ensure p12 (subject created when s1 runs p2) cant write to f3 In practice, p12 inherits s1s rightsbad! Note s1 does not own f3, so cant change its rights over f3
Ideally, p12 has capability { (s1, p2, x ) } so no problem
Solution: restrict access by others

November 1, 2004
Authorization Denial Subset

Defined for each user si Contains ACL entries that others cannot exercise over objects si owns In example: R(s2) = { (s1, f3, w) }
So when p12 tries to write to f3, as p12 owned by s1 and f3 owned by s2, system denies access
Problem: how do you decide what should be in your authorization denial subset?
Kargers Scheme
Base it on attribute of subject, object Interpose a knowledge-based subsystem to determine if requested file access reasonable
Sits between kernel and application
Example: UNIX C compiler

Reads from files with names ending in .c, .h Writes to files with names beginning with /tmp/ctm and assembly files with names ending in .s
When subsystem invoked, if C compiler tries to write to .c file, request rejected

Lai and Gray

Implemented modified version of Kargers scheme on UNIX system
Allow programs to access (read or write) files named on command line Prevent access to other files
Two types of processes

Trusted (no access checks or restrictions) Untrusted (valid access list controls access)
VAL initialized to command line arguments plus any temporary files that the process creates
File Access Requests

1. If file on VAL, use effective UID/GID of process to determine if access allowed 2. If access requested is read and file is worldreadable, allow access 3. If process creating file, effective UID/GID controls allowing creation
Enter file into VAL as NNA (new non-argument); set permissions so no other process can read file
4. Ask user. If yes, effective UID/GID controls allowing access; if no, deny access
Example
Assembler invoked from compiler
as x . s/ tmp/c tm2345
and creates temp file /tmp/as1111

VAL is
x .s / tmp/c tm2345 / t mp/as1111
Now Trojan horse tries to copy x.s to another file

On creation, file inaccessible to all except creating user so attacker cannot read it (rule 3) If file created already and assembler tries to write to it, user is asked (rule 4), thereby revealing Trojan horse
Trusted Programs
No VALs applied here
UNIX command interpreters
csh, sh
Program that spawn them

getty, login
Programs that access file system recursively

ar, chgrp, chown, diff, du, dump, find, ls, restore, tar
Programs that often access files not in argument list

binmail, cpp, dbx, mail, make, script, vi
Various network daemons

fingerd, ftpd, sendmail, talkd, telnetd, tftpd
Guardians, Watchdogs
System intercepts request to open file Program invoked to determine if access is to be allowed
These are guardians or watchdogs
Effectively redefines system (or library) calls
November 1, 2004
Slide #1-739
Trust
Trust the user to take explicit actions to limit their process protection domain sufficiently
That is, enforce least privilege correctly
Trust mechanisms to describe programs expected actions sufficiently for descriptions to be applied, and to handle commands without such descriptions properly Trust specific programs and kernel
Problem: these are usually the first programs malicious logic attack
Sandboxing
Sandboxes, virtual machines also restrict rights
Modify program by inserting instructions to cause traps when violation of policy Replace dynamic load libraries with instrumented routines
November 1, 2004
Slide #1-741
Example: Race Conditions

Occur when successive system calls operate on object
Both calls identify object by name Rebind name to different object between calls
Sandbox: instrument calls:

Unique identifier (inode) saved on first call On second call, inode of named file compared to that of first call
If they differ, potential attack underway
Inhibit Sharing
Use separation implicit in integrity policies Example: LOCK keeps single copy of shared procedure in memory
Master directory associates unique owner with each procedure, and with each user a list of other users the first trusts Before executing any procedure, system checks that user executing procedure trusts procedure owner
Multilevel Policies
Put programs at the lowest security level, all subjects at higher levels
By *-property, nothing can write to those programs By ss-property, anything can read (and execute) those programs
Example: DG/UX system

All executables in virus protection region below user and administrative regions
Detect Alteration of Files

Compute manipulation detection code (MDC) to generate signature block for each file, and save it Later, recompute MDC and compare to stored MDC
If different, file has changed
Example: tripwire
Signature consists of file attributes, cryptographic checksums chosen from among MD4, MD5, HAVAL, SHS, CRC-16, CRC-32, etc.)
Assumptions
Files do not contain malicious logic when original signature block generated Pozzo & Grey: implement Bibas model on LOCUS to make assumption explicit
Credibility ratings assign trustworthiness numbers from 0 (untrusted) to n (signed, fully trusted) Subjects have risk levels
Subjects can execute programs with credibility ratings risk level If credibility rating < risk level, must use special command to run program
Antivirus Programs
Look for specific sequences of bytes (called virus signature in file
If found, warn user and/or disinfect file
Each agent must look for known set of viruses Cannot deal with viruses not yet analyzed
Due in part to undecidability of whether a generic program is a virus
Detect Actions Beyond Spec

Treat execution, infection as errors and apply fault tolerant techniques Example: break program into sequences of nonbranching instructions
Checksum each sequence, encrypt result When run, processor recomputes checksum, and at each branch co-processor compares computed checksum with stored one
If different, error occurred
N-Version Programming
Implement several different versions of algorithm Run them concurrently
Check intermediate results periodically If disagreement, majority wins
Assumptions
Majority of programs not infected Underlying operating system secure Different algorithms with enough equal intermediate results may be infeasible
Especially for malicious logic, where you would check file accesses
Proof-Carrying Code
Code consumer (user) specifies safety requirement Code producer (author) generates proof code meets this requirement
Proof integrated with executable code Changing the code invalidates proof
Binary (code + proof) delivered to consumer Consumer validates proof Example statistics on Berkeley Packet Filter: proofs 300900 bytes, validated in 0.3 1.3 ms
Startup cost higher, runtime cost considerably shorter
Detecting Statistical Changes

Example: application had 3 programmers working on it, but statistical analysis shows code from a fourth personmay be from a Trojan horse or virus! Other attributes: more conditionals than in original; look for identical sequences of bytes not common to any library routine; increases in file size, frequency of writing to executables, etc.
Denning: use intrusion detection system to detect these
Key Points
A perplexing problem
How do you tell what the user asked for is not what the user intended?
Strong typing leads to separating data, instructions File scanners most popular anti-virus agents
Must be updated as new viruses come out
Chapter 20: Vulnerability Analysis

Background Penetration Studies Example Vulnerabilities Classification Frameworks
November 1, 2004
Slide #1-753
Overview
What is a vulnerability? Penetration studies
Flaw Hypothesis Methodology Examples
Vulnerability examples Classification schemes

RISOS PA NRL Taxonomy Aslams Model
November 1, 2004
Definitions
Vulnerability, security flaw: failure of security policies, procedures, and controls that allow a subject to commit an action that violates the security policy
Subject is called an attacker Using the failure to violate the policy is exploiting the vulnerability or breaking in
Formal Verification
Mathematically verifying that a system satisfies certain constraints Preconditions state assumptions about the system Postconditions are result of applying system operations to preconditions, inputs Required: postconditions satisfy constraints
Penetration Testing
Testing to verify that a system satisfies certain constraints Hypothesis stating system characteristics, environment, and state relevant to vulnerability Result is compromised system state Apply tests to try to move system from state in hypothesis to compromised system state
November 1, 2004
Slide #1-757
Notes
Penetration testing is a testing technique, not a verification technique
It can prove the presence of vulnerabilities, but not the absence of vulnerabilities
For formal verification to prove absence, proof and preconditions must include all external factors
Realistically, formal verification proves absence of flaws within a particular program, design, or environment and not the absence of flaws in a computer system (think incorrect configurations, etc.)
Penetration Studies
Test for evaluating the strengths and effectiveness of all security controls on system
Also called tiger team attack or red team attack Goal: violate site security policy Not a replacement for careful design, implementation, and structured testing Tests system in toto, once it is in place
Includes procedural, operational controls as well as technological ones
November 1, 2004
Slide #1-759
Goals
Attempt to violate specific constraints in security and/or integrity policy
Implies metric for determining success Must be well-defined
Example: subsystem designed to allow owner to require others to give password before accessing file (i.e., password protect files)
Goal: test this control Metric: did testers get access either without a password or by gaining unauthorized access to a password?
Goals
Find some number of vulnerabilities, or vulnerabilities within a period of time
If vulnerabilities categorized and studied, can draw conclusions about care taken in design, implementation, and operation Otherwise, list helpful in closing holes but not more
Example: vendor gets confidential documents, 30 days later publishes them on web
Goal: obtain access to such a file; you have 30 days Alternate goal: gain access to files; no time limit (a Trojan horse would give access for over 30 days)
Layering of Tests
1. External attacker with no knowledge of system
Locate system, learn enough to be able to access it
2. External attacker with access to system

Can log in, or access network servers Often try to expand level of access
3. Internal attacker with access to system

Testers are authorized users with restricted accounts (like ordinary users) Typical goal is to gain unauthorized privileges or information
Layering of Tests (cont)

Studies conducted from attackers point of view Environment is that in which attacker would function If information about a particular layer irrelevant, layer can be skipped
Example: penetration testing during design, development skips layer 1 Example: penetration test on system with guest account usually skips layer 2
Methodology
Usefulness of penetration study comes from documentation, conclusions
Indicates whether flaws are endemic or not It does not come from success or failure of attempted penetration
Degree of penetrations success also a factor

In some situations, obtaining access to unprivileged account may be less successful than obtaining access to privileged account November 1, 2004 Introduction to Computer Security Slide #1-764
2004 Matt Bishop
Flaw Hypothesis Methodology

1. Information gathering
Become familiar with systems functioning
2. Flaw hypothesis
Draw on knowledge to hypothesize vulnerabilities
3. Flaw testing
Test them out
4. Flaw generalization
Generalize vulnerability to find others like it
5. (maybe) Flaw elimination

Testers eliminate the flaw (usually not included)
Information Gathering
Devise model of system and/or components
Look for discrepencies in components Consider interfaces among components
Need to know system well (or learn quickly!)

Design documents, manuals help
Unclear specifications often misinterpreted, or interpreted differently by different people
Look at how system manages privileged users

Flaw Hypothesizing
Examine policies, procedures
May be inconsistencies to exploit May be consistent, but inconsistent with design or implementation May not be followed
Examine implementations
Use models of vulnerabilities to help locate potential problems Use manuals; try exceeding limits and restrictions; try omitting steps in procedures
Flaw Hypothesizing (cont)

Identify structures, mechanisms controlling system
These are what attackers will use Environment in which they work, and were built, may have introduced errors
Throughout, draw on knowledge of other systems with similarities

Which means they may have similar vulnerabilities
Result is list of possible flaws

Flaw Testing
Figure out order to test potential flaws
Priority is function of goals
Example: to find major design or implementation problems, focus on potential system critical flaws Example: to find vulnerability to outside attackers, focus on external access protocols and programs
Figure out how to test potential flaws

Best way: demonstrate from the analysis
Common when flaw arises from faulty spec, design, or operation
Otherwise, must try to exploit it

Flaw Testing (cont)

Design test to be least intrusive as possible
Must understand exactly why flaw might arise
Procedure
Back up system Verify system configured to allow exploit
Take notes of requirements for detecting flaw
Verify existence of flaw

May or may not require exploiting the flaw Make test as simple as possible, but success must be convincing
Must be able to repeat test successfully

Flaw Generalization
As tests succeed, classes of flaws emerge
Example: programs read input into buffer on stack, leading to buffer overflow attack; others copy command line arguments into buffer on stack these are vulnerable too
Sometimes two different flaws may combine for devastating attack

Example: flaw 1 gives external attacker access to unprivileged account on system; second flaw allows any user on that system to gain full privileges any external attacker can get full privileges
Flaw Elimination
Usually not included as testers are not best folks to fix this
Designers and implementers are
Requires understanding of context, details of flaw including environment, and possibly exploit
Design flaw uncovered during development can be corrected and parts of implementation redone
Dont need to know how exploit works
Design flaw uncovered at production site may not be corrected fast enough to prevent exploitation
So need to know how exploit works
Michigan Terminal System

General-purpose OS running on IBM 360, 370 systems Class exercise: gain access to terminal control structures
Had approval and support of center staff Began with authorized account (level 3)
November 1, 2004
Slide #1-773
Step 1: Information Gathering

Learn details of systems control flow and supervisor
When program ran, memory split into segments 0-4: supervisor, system programs, system state
Protected by hardware mechanisms
5: system work area, process-specific information including privilege level

Process should not be able to alter this
6 on: user process information

Process can alter these
Focus on segment 5

Segment 5 protected by virtual memory protection system
System mode: process can access, alter data in segment 5, and issue calls to supervisor User mode: segment 5 not present in process address space (and so cant be modified)
Run in user mode when user code being executed User code issues system call, which in turn issues supervisor call
How to Make a Supervisor Call

System code checks parameters to ensure supervisor accesses authorized locations only
Parameters passed as list of addresses (X, X+1, X+2) constructed in user segment Address of list (X) passed via register
X+2
X X + 1X+ 2
Step 3: Flaw Hypothesis

Consider switch from user to system mode
System mode requires supervisor privileges
Found: a parameter could point to another element in parameter list

Below: address in location X+1 is that of parameter at X+2 Means: system or supervisor procedure could alter parameters address after checking validity of old address
X+2
X X + 1X+ 2
Step 4: Flaw Testing

Find a system routine that:
Used this calling convention; Took at least 2 parameters and altered 1 Could be made to change parameter to any value (such as an address in segment 5)
Chose line input routine

Returns line number, length of line, line read
Setup:
Set address for storing line number to be address of line length
Step 5: Execution
System routine validated all parameter addresses
All were indeed in user segment
Supervisor read input line

Line length set to value to be written into segment 5
Line number stored in parameter list

Line number was set to be address in segment 5
When line read, line length written into location address of which was in parameter list
So it overwrote value in segment 5
Step 6: Flaw Generalization

Could not overwrite anything in segments 0-4
Protected by hardware
Testers realized that privilege level in segment 5 controlled ability to issue supervisor calls (as opposed to system calls)
And one such call turned off hardware protection for segments 0-4
Effect: this flaw allowed attackers to alter anything in memory, thereby completely controlling computer
Burroughs B6700
System architecture: based on strict file typing
Entities: ordinary users, privileged users, privileged programs, OS tasks
Ordinary users tightly restricted Other 3 can access file data without restriction but constrained from compromising integrity of system
No assemblers; compilers output executable code Data files, executable files have different types
Only compilers can produce executables Writing to executable or its attributes changes its type to data
Class exercise: obtain status of privileged user


System had tape drives
Writing file to tape preserved file contents Header record prepended to tape that indicates file attributes including type
Data could be copied from one tape to another

If you change data, its still data

System cannot detect change to executable file if that file is altered off-line
November 1, 2004
Slide #1-783

Write small program to change type of any file from data to executable
Compiled, but could not be used yet as it would alter file attributes, making target a data file Write this to tape
Write a small utility to copy contents of tape 1 to tape 2

Utility also changes header record of contents to indicate file was a compiler (and so could output executables)
Creating the Compiler

Run copy program
As header record copied, type becomes compiler
Reinstall program as a new compiler Write new subroutine, compile it normally, and change machine code to give privileges to anyone calling it (this makes it data, of course)
Now use new compiler to change its type from data to executable
Write third program to call this

Now you have privileges
Corporate Computer System

Goal: determine whether corporate security measures were effective in keeping external attackers from accessing system Testers focused on policies and procedures
Both technical and non-technical
November 1, 2004
Slide #1-786

Searched Internet
Got names of employees, officials Got telephone number of local branch, and from them got copy of annual report
Constructed much of the companys organization from this data

Including list of some projects on which individuals were working
Step 2: Get Telephone Directory

Corporate directory would give more needed information about structure
Tester impersonated new employee
Learned two numbers needed to have something delivered offsite: employee number of person requesting shipment, and employees Cost Center number
Testers called secretary of executive they knew most about

One impersonated an employee, got executives employee number Another impersonated auditor, got Cost Center number
Had corporate directory sent to off-site subcontractor


Controls blocking people giving passwords away not fully communicated to new employees
Testers impersonated secretary of senior executive
Called appropriate office Claimed senior executive upset he had not been given names of employees hired that week Got the names

Testers called newly hired people
Claimed to be with computer center Provided Computer Security Awareness Briefing over phone During this, learned:
Types of comnputer systems used Employees numbers, logins, and passwords
Called computer center to get modem numbers

These bypassed corporate firewalls
Success
Penetrating a System
Goal: gain access to system We know its network address and nothing else First step: scan network ports of system
Protocols on ports 79, 111, 512, 513, 514, and 540 are typically run on UNIX systems
Assume UNIX system; SMTP agent probably sendmail

This program has had lots of security problems Maybe system running one such version
Next step: connect to sendmail on port 25

Output of Network Scan

f tp te lne t smtp f inger sunrpc exec l og in she l l pr in te r uucp nfs x term 21 / tcp F i le Trans fer 23 / t cp Te lnet 25 / t cp S imp le Mail T rans f er 79 / t cp F inger 111/ tcp SU N Remote Procedure Ca l l 512/ t cp remote process execut i on ( rexecd) 513/ t cp remote log i n( r log i nd) 514/ t cp r logi ns ty le exec ( r shd) 515/ t cp spoo ler ( lpd) 540/ t cp uucpd 2049/t cp ne t worked f i l e system 6000/ tcp x windows server
November 1, 2004
Output of sendmail
220 zzz .com sendma i l3 .1 / zzz .3 .9, Da l las, Texas,ready at Wed, 2 Apr 97 22:07:31 CST Version 3.1 has the wiz vulnerability that recognizes the shell command so lets try it Start off by identifying yourself he lo xxx .org 250 zzz .com Hel lo xxx .org ,p leased to meet you Now see if the wiz command works if it says command unrecognized, were out of luck wiz 250 Ente r , O mighty wizard ! It does! And we didnt need a password so get a shell she l l # And we have full privileges as the superuser, root
Penetrating a System (Revisited)

Goal: from an unprivileged account on system, gain privileged access First step: examine system
See it has dynamically loaded kernel Program used to add modules is loadmodule and must be privileged So an unprivileged user can run a privileged program this suggests an interface that controls this Question: how does loadmodule work?
November 1, 2004
Slide #1-794
loadmodule
Validates module ad being a dynamic load module Invokes dynamic loader ld.so to do actual load; also calls arch to determine system architecture (chip set)
Check, but only privileged user can call ld.so
How does loadmodule execute these programs?

Easiest way: invoke them directly using system(3), which does not reset environment when it spawns subprogram
First Try
Set environment to look in local directory, write own version of ld.so, and put it in local directory
This version will print effective UID, to demonstrate we succeeded
Set search path to look in current working directory before system directories Then run loadmodule
Nothing is printeddarn! Somehow changing environment did not affect execution of subprogramswhy not?
What Happened
Look in executable to see how ld.so, arch invoked
Invocations are /bin/ld.so, /bin/arch Changing search path didnt matter as never used
Reread system(3) manual page

It invokes command interpreter sh to run subcommands
Read sh(1) manual page

Uses IFS environment variable to separate words These are by default blanks can we make it include a /?
If so, sh would see /bin/ld.so as bin followed by ld.so, so it would look for command bin
Second Try
Change value of IFS to include / Change name of our version of ld.so to bin
Search path still has current directory as first place to look for commands
Run loadmodule
Prints that its effective UID is 0 (root)
Success!
Generalization
Process did not clean out environment before invoking subprocess, which inherited environment
So, trusted program working with untrusted environment (input) result should be untrusted, but is trusted!
Look for other privileged programs that spawn subcommands

Especially if they do so by calling system(3)
Penetrating s System redux

Goal: gain access to system We know its network address and nothing else First step: scan network ports of system
Protocols on ports 17, 135, and 139 are typically run on Windows NT server systems
November 1, 2004
Slide #1-800
Output of Network Scan

qotd 17 / t cp Quote o ft he Day f tp 21 / tcp F i le Trans fer[Cont r o l ] l oc -s rv 135/ t cp Locat ion Serv ice netb ios-ssn 139/ tcp NETBIO S Sess ion Serv ice [ JBP]
November 1, 2004
Slide #1-801
First Try
Probe for easy-to-guess passwords
Find system administrator has password Admin Now have administrator (full) privileges on local system
Now, go for rights to other systems in domain

Next Step
Domain administrator installed service running with domain admin privileges on local system Get program that dumps local security authority database
This gives us service account password We use it to get domain admin privileges, and can access any system in domain
Generalization
Sensitive account had an easy-to-guess password
Possible procedural problem
Look for weak passwords on other systems, accounts Review company security policies, as well as education of system administrators and mechanisms for publicizing the policies
Debate
How valid are these tests?
Not a substitute for good, thorough specification, rigorous design, careful and correct implementation, meticulous testing Very valuable a posteriori testing technique
Ideally unnecessary, but in practice very necessary
Finds errors introduced due to interactions with users, environment

Especially errors from incorrect maintenance and operation Examines system, site through eyes of attacker
Problems
Flaw Hypothesis Methodology depends on caliber of testers to hypothesize and generalize flaws Flaw Hypothesis Methodology does not provide a way to examine system systematically
Vulnerability classification schemes help here
Vulnerability Classification
Describe flaws from differing perspectives
Exploit-oriented Hardware, software, interface-oriented
Goals vary; common ones are:

Specify, design, implement computer system without vulnerabilities Analyze computer system to detect vulnerabilities Address any vulnerabilities introduced during system operation Detect attempted exploitations of vulnerabilities
November 1, 2004
Slide #1-807
Example Flaws
Use these to compare classification schemes First one: race condition (xterm) Second one: buffer overflow on stack leading to execution of injected code (fingerd) Both are very well known, and fixes available!
And should be installed everywhere
Flaw #1: xterm

xterm emulates terminal under X11 window system
Must run as root user on UNIX systems
No longer universally true; reason irrelevant here
Log feature: user can log all input, output to file

User names file If file does not exist, xterm creates it, makes owner the user If file exists, xterm checks user can write to it, and if so opens file to append log to it
November 1, 2004
Slide #1-809
File Exists
Check that user can write to file requires special system call
Because root can append to any file, check in open will always succeed
Check that user can write to file /usr/tom/X i f(access( /usr / t om/X , W _ O K) == 0) { Open /usr/tom/X to append log entries i f( ( fd = open( /usr / tom/X , O_ W R O NLY|O_APPEN D))< 0) { / * hand l e er ror :cannot open f i le * / } }
November 1, 2004
Slide #1-810
Problem
Binding of file name /usr/tom/X to file object can change between first and second lines
(a) is at access; (b) is at open Note file opened is not file checked
/ etc passwd passwd data usr X tom etc passwd passwd data / usr X tom X data
X data
access(/usr/tom/X, W_OK) (a)

November 1, 2004
open(/usr/tom/X, O_WRITE) (b)

Slide #1-811
Flaw #2: fingerd

Exploited by Internet Worm of 1988
Recurs in many places, even now
finger client send request for information to server fingerd (finger daemon)
Request is name of at most 512 chars What happens if you send more?
November 1, 2004
Slide #1-812
Buffer Overflow
Extra chars overwrite rest of stack, as shown Can make those chars change return address to point to beginning of buffer If buffer contains small program to spawn shell, attacker gets shell on target system
getslocal variables other return state info return address ofmain parameter to gets input buffer mainlocal variables getslocal variables other return state info address of input buffer program to invoke shell mainlocal variables
After message
November 1, 2004
Slide #1-813
Frameworks
Goals dictate structure of classification scheme
Guide development of attack tool focus is on steps needed to exploit vulnerability Aid software development process focus is on design and programming errors causing vulnerabilities
Following schemes classify vulnerability as n-tuple, each element of ntuple being classes into which vulnerability falls
Some have 1 axis; others have multiple axes
November 1, 2004
Slide #1-814
Research Into Secure Operating Systems (RISOS)

Goal: aid computer, system managers in understanding security issues in OSes, and help determine how much effort required to enhance system security Attempted to develop methodologies and software for detecting some problems, and techniques for avoiding and ameliorating other problems Examined Multics, TENEX, TOPS-10, GECOS, OS/MVT, SDS-940, EXEC-8
November 1, 2004
Slide #1-815
Classification Scheme
Incomplete parameter validation Inconsistent parameter validation Imnplicit sharing f privileged/confidential data Asynchronous validation/inadequate serialization Inadequate identification/authentication/authorization Violable prohibition/limit Exploitable logic error
November 1, 2004
Slide #1-816
Incomplete Parameter Validation

Parameter not checked before use Example: emulating integer division in kernel (RISC chip involved)
Caller provided addresses for quotient, remainder Quotient address checked to be sure it was in users protection domain Remainder address not checked
Set remainder address to address of process level of privilege Compute 25/5 and you have level 0 (kernel) privileges
Check for type, format, range of values, access rights, presence (or absence)
Inconsistent Parameter Validation

Each routine checks parameter is in proper format for that routine but the routines require different formats Example: each database record 1 line, colons separating fields
One program accepts colons, newlines as pat of data within fields Another program reads them as field and record separators This allows bogus records to be entered
November 1, 2004
Slide #1-818
Implicit Sharing of Privileged / Confidential Data

OS does not isolate users, processes properly Example: file password protection
OS allows user to determine when paging occurs Files protected by passwords
Passwords checked char by char; stops at first incorrect char
Position guess for password so page fault occurred between 1st, 2nd char
If no page fault, 1st char was wrong; if page fault, it was right
Continue until password discovered
November 1, 2004
Slide #1-819
Asynchronous Validation / Inadequate Serialization

Time of check to time of use flaws, intermixing reads and writes to create inconsistencies Example: xterm flaw discussed earlier
November 1, 2004
Slide #1-820
Inadequate Identification / Authorization / Authentication

Erroneously identifying user, assuming anothers privilege, or tricking someone into executing program without authorization Example: OS on which access to file named SYS$*DLOC$ meant process privileged
Check: can process access any file with qualifier name beginning with SYS and file name beginning with DLO? If your process can access file SYSA*DLOC$, which is ordinary file, your process is privileged
November 1, 2004
Slide #1-821
Violable Prohibition / Limit

Boundary conditions not handled properly Example: OS kept in low memory, user process in high memory
Boundary was highest address of OS All memory accesses checked against this Memory accesses not checked beyond end of high memory
Such addresses reduced modulo memory size
So, process could access (memory size)+1, or word 1, which is part of OS
November 1, 2004
Slide #1-822
Exploitable Logic Error

Problems not falling into other classes
Incorrect error handling, unexpected side effects, incorrect resource allocation, etc.
Example: unchecked return from monitor

Monitor adds 1 to address in users PC, returns
Index bit (indicating indirection) is a bit in word Attack: set address to be 1; adding 1 overflows, changes index bit, so return is to location stored in register 1
Arrange for this to point to bootstrap program stored in other registers

On return, program executes with system privileges
November 1, 2004
Slide #1-823
Legacy of RISOS
First funded project examining vulnerabilities Valuable insight into nature of flaws
Security is a function of site requirements and threats Small number of fundamental flaws recurring in many contexts OS security not critical factor in design of OSes
Spurred additional research efforts into detection, repair of vulnerabilities
November 1, 2004
Slide #1-824
Program Analysis (PA)

Goal: develop techniques to find vulnerabilities Tried to break problem into smaller, more manageable pieces Developed general strategy, applied it to several OSes
Found previously unknown vulnerabilities
Classification Scheme
Improper protection domain initialization and enforcement
Improper choice of initial protection domain Improper isolation of implementation detail Improper change Improper naming Improper deallocation or deletion
Improper validation Improper synchronization

Improper indivisibility Improper sequencing
Improper choice of operand or operation
November 1, 2004
Slide #1-826
Improper Choice of Initial Protection Domain

Initial incorrect assignment of privileges, security and integrity classes Example: on boot, protection mode of file containing identifiers of all users can be altered by any user
Under most policies, should not be allowed
November 1, 2004
Slide #1-827
Improper Isolation of Implementation Detail

Mapping an abstraction into an implementation in such a way that the abstraction can be bypassed Example: VMs modulate length of time CPU is used by each to send bits to each other Example: Having raw disk accessible to system as ordinary file, enabling users to bypass file system abstraction and write directly to raw disk blocks
November 1, 2004
Slide #1-828
Improper Change
Data is inconsistent over a period of time Example: xterm flaw
Meaning of /usr/tom/X changes between access and open
Example: parameter is validated, then accessed; but parameter is changed between validation and access
Burroughs B6700 allowed allowed this
Improper Naming
Multiple objects with same name Example: Trojan horse
loadmodule attack discussed earlier; bin could be a directory or a program
Example: multiple hosts with same IP address

Messages may be erroneously routed
Improper Deallocation or Deletion

Failing to clear memory or disk blocks (or other storage) after it is freed for use by others Example: program that contains passwords that a user typed dumps core
Passwords plainly visible in core dump
November 1, 2004
Slide #1-831
Improper Validation
Inadequate checking of bounds, type, or other attributes or values Example: fingerds failure to check input length
November 1, 2004
Slide #1-832
Improper Indivisibility
Interrupting operations that should be uninterruptable
Often: interrupting atomic operations
Example: mkdir flaw (UNIX Version 7)

Created directories by executing privileged operation to create file node of type directory, then changed ownership to user On loaded system, could change binding of name of directory to be that of password file after directory created but before change of ownership Attacker can change administrators password
November 1, 2004
Slide #1-833
Improper Sequencing
Required order of operations not enforced Example: one-time password scheme
System runs multiple copies of its server Two users try to access same account
Server 1 reads password from file Server 2 reads password from file Both validate typed password, allow user to log in Server 1 writes new password to file Server 2 writes new password to file
Should have every read to file followed by a write, and vice versa; not two reads or two writes to file in a row
November 1, 2004
Slide #1-834
Improper Choice of Operand or Operation

Calling inappropriate or erroneous instructions Example: cryptographic key generation software calling pseudorandom number generators that produce predictable sequences of numbers
November 1, 2004
Slide #1-835
Legacy
First to explore automatic detection of security flaws in programs and systems Methods developed but not widely used
Parts of procedure could not be automated Complexity Procedures for obtaining system-independent patterns describing flaws not complete
NRL Taxonomy
Goals:
Determine how flaws entered system Determine when flaws entered system Determine where flaws are manifested in system
3 different schemes used:

Genesis of flaws Time of flaws Location of flaws
November 1, 2004
Slide #1-837
Genesis of Flaws
Nonreplicating Trojan horse Malicious Intentional Covert channel Nonmalicious Other Trapdoor Logic/time bomb Replicating
Storage Timing
Inadvertent (unintentional) flaws classified using RISOS categories; not shown above
If most inadvertent, better design/coding reviews needed If most intentional, need to hire more trustworthy developers and do more securityrelated testing
November 1, 2004
Slide #1-838
Time of Flaws
Development Time of introduction Maintenance Operation Requirement/specification/design Source code Object code
Development phase: all activities up to release of initial version of software Maintenance phase: all activities leading to changes in software performed under configuration control Operation phase: all activities involving patching and not under configuration control
November 1, 2004
Location of Flaw
Operating system Software Location Hardware Support Application System initialization Memory management Process management/scheduling Device management File management Identification/authentication Other/unkno wn Privileged utilities Unprivileged utilities
Focus effort on locations where most flaws occur, or where most serious flaws occur
November 1, 2004
Slide #1-840
Legacy
Analyzed 50 flaws Concluded that, with a large enough sample size, an analyst could study relationships between pairs of classes
This would help developers focus on most likely places, times, and causes of flaws
Focused on social processes as well as technical details

But much information required for classification not available for the 50 flaws
November 1, 2004
Slide #1-841
Aslams Model
Goal: treat vulnerabilities as faults and develop scheme based on fault trees Focuses specifically on UNIX flaws Classifications unique and unambiguous
Organized as a binary tree, with a question at each node. Answer determines branch you take Leaf node gives you classification
Suited for organizing flaws in a database

Top Level
Coding faults: introduced during software development
Example: fingerds failure to check length of input string before storing it in buffer
Emergent faults: result from incorrect initialization, use, or application

Example: allowing message transfer agent to forward mail to arbitrary file on system (it performs according to specification, but results create a vulnerability)
November 1, 2004
Slide #1-843
Coding Faults
Synchronization errors: improper serialization of operations, timing window between two operations creates flaw
Example: xterm flaw
Condition validation errors: bounds not checked, access rights ignored, input not validated, authentication and identification fails
Example: fingerd flaw
November 1, 2004
Slide #1-844
Emergent Faults
Configuration errors: program installed incorrectly
Example: tftp daemon installed so it can access any file; then anyone can copy any file
Environmental faults: faults introduced by environment

Example: on some UNIX systems, any shell with - as first char of name is interactive, so find a setuid shell script, create a link to name -gotcha, run it, and you has a privileged interactive shell
November 1, 2004
Slide #1-845
Legacy
Tied security flaws to software faults Introduced a precise classification scheme
Each vulnerability belongs to exactly 1 class of security flaws Decision procedure well-defined, unambiguous
November 1, 2004
Slide #1-846
Comparison and Analysis

Point of view
If multiple processes involved in exploiting the flaw, how does that affect classification?
xterm, fingerd flaws depend on interaction of two processes (xterm and process to switch file objects; fingerd and its client)
Levels of abstraction
How does flaw appear at different levels?
Levels are abstract, design, implementation, etc.
xterm and PA Classification

Implementation level
xterm: improper change attackers program: improper deallocation or deletion operating system: improper indivisibility
November 1, 2004
Slide #1-848
xterm and PA Classification

Consider higher level of abstraction, where directory is simply an object
create, delete files maps to writing; read file status, open file maps to reading operating system: improper sequencing
During read, a write occurs, violating Bernstein conditions
Consider even higher level of abstraction

attackers process: improper choice of initial protection domain
Should not be able to write to directory containing log file Semantics of UNIX users require this at lower levels
November 1, 2004
Slide #1-849
xterm and RISOS Classification

xterm: asynchronous validation/inadequate serialization attackers process: exploitable logic error and violable prohibition/limit operating system: inconsistent parameter validation
November 1, 2004
Slide #1-850
xterm and RISOS Classification

Consider higher level of abstraction, where directory is simply an object (as before)
all: asynchronous validation/inadequate serialization
Consider even higher level of abstraction

attackers process: inadequate identification/authentication/authorization
Directory with log file not protected adequately Semantics of UNIX require this at lower levels
xterm and NRL Classification

Time, location unambiguous
Time: during development Location: Support:privileged utilities
Genesis: ambiguous
If intentional:
Lowest level: inadvertent flaw of serialization/aliasing
If unintentional:
Lowest level: nonmalicious: other
At higher levels, parallels that of RISOS
November 1, 2004
Slide #1-852
xterm and Aslams Classification

attackers process: object installed with incorrect permissions
attackers process can delete file
xterm: access rights validation error

xterm doesnt properly valisate file at time of access
operating system: improper or inadequate serialization error

deletion, creation should not have been interspersed with access, open
Note: in absence of explicit decision procedure, all could go into class race condition
November 1, 2004
Slide #1-853
The Point
The schemes lead to ambiguity
Different researchers may classify the same vulnerability differently for the same classification scheme
Not true for Aslams, but that misses connections between different classifications
xterm is race condition as well as others; Aslam does not show this
fingerd and PA Classification

fingerd: improper validation attackers process: improper choice of operand or operation operating system: improper isolation of implementation detail
November 1, 2004
Slide #1-855
fingerd and PA Classification

Consider higher level of abstraction, where storage space of return address is object
operating system: improper change fingerd: improper validation
Because it doesnt validate the type of instructions to be executed, mistaking data for valid ones
Consider even higher level of abstraction, where securityrelated value in memory is changing and data executed that should not be executable
operating system: improper choice of initial protection domain
November 1, 2004
Slide #1-856
fingerd and RISOS Classification

fingerd: incomplete parameter validation attackers process: violable prohibition/limit operating system: inadequate identification/authentication/authorization
November 1, 2004
Slide #1-857
fingerd and RISOS Classification

Consider higher level of abstraction, where storage space of return address is object
operating system: asynchronous validation/inadequate serialization fingerd: inadequate identification/authentication/authorization
Consider even higher level of abstraction, where securityrelated value in memory is changing and data executed that should not be executable
operating system: inadequate identification/authentication/authorization
November 1, 2004
Slide #1-858
fingerd and NRL Classification

Time, location unambiguous
Time: during development Location: support: privileged utilities
Genesis: ambiguous
Known to be inadvertent flaw Parallels that of RISOS
November 1, 2004
Slide #1-859
fingerd and Aslam Classification

fingerd: boundary condition error attackers process: boundary condition error
operating system: environmental fault
If decision procedure not present, could also have been access rights validation errors
November 1, 2004
Slide #1-860
Summary
Classification schemes requirements
Decision procedure for classifying vulnerability Each vulnerability should have unique classification
Above schemes do not meet these criteria

Inconsistent among different levels of abstraction Point of view affects classification
Key Points
Given large numbers of non-secure systems in use now, unrealistic to expect less vulnerable systems to replace them Penetration studies are effective tests of systems provided the test goals are known and tests are structured well Vulnerability classification schemes aid in flaw generalization and hypothesis
Chapter 21: Auditing

Overview What is auditing? What does an audit system look like? How do you design an auditing system? Auditing mechanisms Examples: NFSv2, LAFS
November 1, 2004
What is Auditing?
Logging
Recording events or statistics to provide information about system use and performance
Auditing
Analysis of log records to present information about the system in a clear, understandable manner
November 1, 2004
Slide #1-864
Uses
Describe security state
Determine if system enters unauthorized state
Evaluate effectiveness of protection mechanisms

Determine which mechanisms are appropriate and working Deter attacks because of presence of record
Problems
What do you log?
Hint: looking for violations of a policy, so record at least what will show such violations
What do you audit?

Need not audit everything Key: what is the policy involved?
November 1, 2004
Slide #1-866
Audit System Structure

Logger
Records information, usually controlled by parameters
Analyzer
Analyzes logged information looking for something
Notifier
Reports results of analysis
Logger
Type, quantity of information recorded controlled by system or program configuration parameters May be human readable or not
If not, usually viewing tools supplied Space available, portability influence storage format
Example: RACF
Security enhancement package for IBMs MVS/VM Logs failed access attempts, use of privilege to change security levels, and (if desired) RACF interactions View events with LISTUSERS commands
November 1, 2004
Slide #1-869
RACF: Sample Entry

USE R=EW 125004 NA ME=S.J .TURNE R OW N E R=SECA D M CREATED=88.004 DEFAULT-GR O UP=H U M RES PASSDATE=88.004 PASSI NTERVAL=30 ATTRIBUTES=ADSP REV OKE DATE=N O N E RES U M E -DATE=NO N E LAST-AC CESS=88.020/14:15 :10 CLASS AUTH O R IZATIONS=N O NE NOINSTALLATIO N-DATA NO-M O DEL-NAM E LOG O N ALLO W ED (DAYS) (T I M E) ANYDAY ANYTIME GR O U P=HU M R ES AUTH=JOIN CO N N E CT-O W N E R =SECAD M CONN ECT-DATE=88.004 CONNE CTS= 15 UACC=READ LAST-CON NE CT=88.018/16:45 :06 CONNE CT ATTRIBUTES=N O NE REVO KE DATE=N O N E RESUM E DATE=N O NE GR O U P=PERSNL AUTH=JOIN CO N N E CT-O W N E R =SECAD M C O N N ECT-DATE:88.004 CONNE CTS= 25 UACC=READ LAST-CON NE CT=88.020/14:15 :10 CONNE CT ATTRIBUTES=N O NE REVO KE DATE=N O N E RESUM E DATE=N O NE SECURITY-LEVEL=N O NE SPECIFIED CATEG O R Y AUTH O RIZATION NONE SPECIFIED November 1, 2004 Slide #1-870
Example: Windows NT
Different logs for different types of events
System event logs record system crashes, component failures, and other system events Application event logs record events that applications request be recorded Security event log records security-critical events such as logging in and out, system file accesses, and other events
Logs are binary; use event viewer to see them If log full, can have system shut down, logging disabled, or logs overwritten
November 1, 2004
Slide #1-871
Windows NT Sample Entry

Date:2/12/2000 Source: Time: 13:03 Category: Type: Success EventID: User:WINDSOR\Administrator Computer: WINDSOR Security Detailed Tracking 592
Description: A new process has been created: New Process ID: 2216594592 Image File Name: \Program Files\Internet Explorer\IEXPLORE.EXE Creator Process ID: 2217918496 User Name: Administrator FDomain: WINDSOR Logon ID: (0x0,0x14B4c4)
[would be in graphical format]
November 1, 2004
Slide #1-872
Analyzer
Analyzes one or more logs
Logs may come from multiple systems, or a single system May lead to changes in logging May lead to a report of an event
November 1, 2004
Slide #1-873
Examples
Using swatch to find instances of telnet from tcpd logs:
/ te lne t /&! / loca lhos t /& ! / * .s i te .com/
Query set overlap control in databases

If too much overlap between current query and past queries, do not answer
Intrusion detection analysis engine (director)

Takes data from sensors and determines if an intrusion is occurring
November 1, 2004
Slide #1-874
Notifier
Informs analyst, other entities of results of analysis May reconfigure logging and/or analysis on basis of results
November 1, 2004
Slide #1-875
Examples
Using swatch to notify of telnets
/ te lne t / &! / loca l host /& ! / * .s i te .com/ mai ls t af f
Query set overlap control in databases

Prevents response from being given if too much overlap occurs
Three failed logins in a row disable user account

Notifier disables account, notifies sysadmin
Designing an Audit System

Essential component of security mechanisms Goals determine what is logged
Idea: auditors want to detect violations of policy, which provides a set of constraints that the set of possible actions must satisfy So, audit functions that may violate the constraints
Constraint pi : action condition
November 1, 2004
Slide #1-877
Example: Bell-LaPadula
Simple security condition and *-property
S reads O L(S) L(O) S writes O L(S) L(O) To check for violations, on each read and write, must log L(S), L(O), action (read, write), and result (success, failure) Note: need not record S, O!
In practice, done to identify the object of the (attempted) violation and the user attempting the violation
November 1, 2004
Slide #1-878
Show non-security or find violations?
Former requires logging initial state as well as changes
Defining violations
Does write include append and create directory?
Multiple names for one object

Logging goes by object and not name Representations can affect this (if you read raw disks, youre reading files; can your auditing system determine which file?)
November 1, 2004
Slide #1-879
Syntactic Issues
Data that is logged may be ambiguous
BSM: two optional text fields followed by two mandatory text fields If three fields, which of the optional fields is omitted?
Solution: use grammar to ensure welldefined syntax of log files

Example
ent ry: da te hos t prog [ bad ] user [ f rom host ] t o user on t t y date : day t ime host : s t r ing prog : s t r ing : bad :FAILED user : s t r ing t t y : /dev / s t r i ng
Log file entry format defined unambiguously Audit mechanism could scan, interpret entries without confusion
November 1, 2004
Slide #1-881
More Syntactic Issues

Context
Unknown user uses anonymous ftp to retrieve file /etc/passwd Logged as such Problem: which /etc/passwd file?
One in system /etc directory One in anonymous ftp directory /var/ftp/etc, and as ftp thinks /var/ftp is the root directory, /etc/passwd refers to /var/ftp/etc/passwd
Log Sanitization
U set of users, P policy defining set of information C(U) that U cannot see; log sanitized when all information in C(U) deleted from log Two types of P
C(U) cant leave site
People inside site are trusted and information not sensitive to them
C(U) cant leave system

People inside site not trusted or (more commonly) information sensitive to them Dont log this sensitive information
November 1, 2004
Slide #1-883
Logging Organization
Logging system Log Sanitizer Users
Logging system
Sanitizer
Log
Users
Top prevents information from leaving site

Users privacy not protected from system administrators, other administrative personnel
Bottom prevents information from leaving system

Data simply not recorded, or data scrambled before recording
November 1, 2004
Slide #1-884
Reconstruction
Anonymizing sanitizer cannot be undone
No way to recover data from this
Pseudonymizing sanitizer can be undone

Original log can be reconstructed
Importance
Suppose security analysis requires access to information that was sanitized?
Issue
Key: sanitization must preserve properties needed for security analysis If new properties added (because analysis changes), may have to resanitize information
This requires pseudonymous sanitization or the original log
Example
Company wants to keep its IP addresses secret, but wants a consultant to analyze logs for an address scanning attack
Connections to port 25 on IP addresses 10.163.5.10, 10.163.5.11, 10.163.5.12, 10.163.5.13, 10.163.5.14, 10.163.5.15 Sanitize with random IP addresses
Cannot see sweep through consecutive IP addresses
Sanitize with sequential IP addresses

Can see sweep through consecutive IP addresses
November 1, 2004
Slide #1-887
Generation of Pseudonyms
1. Devise set of pseudonyms to replace sensitive information
Replace data with pseudonyms Maintain table mapping pseudonyms to data
2.
Use random key to encipher sensitive datum and use secret sharing scheme to share key
Used when insiders cannot see unsanitized data, but outsiders (law enforcement) need to Requires t out of n people to read data
November 1, 2004
Slide #1-888
Application Logging
Applications logs made by applications
Applications control what is logged Typically use high-level abstractions such as:
su: b i shop to root on / dev/ t t yp0
Does not include detailed, system call level information such as results, parameters, etc.
November 1, 2004
Slide #1-889
System Logging
Log system events such as kernel actions
Typically use low-level events
3876 ktrace 3876 ktrace 3876 ktrace 3876 su 3876 su 3876 su 3876 su 3876 su 3876 su 3876 su CALL NAMI NAMI RET CALL RET CALL RET CALL RET execve(0xbfbff0c0,0xbfbff5cc,0xbfbff5d8) "/usr/bin/su" "/usr/libexec/ld - e lf.so.1" xecve 0 __sysctl(0xbfbff47c,0x2,0x2805c928,0xbfbff478,0,0) __sysctl 0 mmap(0,0x8000,0x3,0x1002,0xffffffff,0,0,0) mmap 671473664/0x2805e000 geteuid geteuid 0
Does not include high-level abstractions such as loading libraries (as above)
November 1, 2004
Slide #1-890
Contrast
Differ in focus
Application logging focuses on application events, like failure to supply proper password, and the broad operation (what was the reason for the access attempt?) System logging focuses on system events, like memory mapping or file accesses, and the underlying causes (why did access fail?)
System logs usually much bigger than application logs Can do both, try to correlate them
November 1, 2004
Slide #1-891
Design
A posteriori design
Need to design auditing mechanism for system not built with security in mind
Goal of auditing
Detect any violation of a stated policy
Focus is on policy and actions designed to violate policy; specific actions may not be known
Detect actions known to be part of an attempt to breach security

Focus on specific actions that have been determined to indicate attacks
November 1, 2004
Slide #1-892
Detect Violations of Known Policy

Goal: does system enter a disallowed state? Two forms
State-based auditing
Look at current state of system
Transition-based auditing
Look at actions that transition system from one state to another
November 1, 2004
Slide #1-893
State-Based Auditing
Log information about state and determine if state allowed
Assumption: you can get a snapshot of system state Snapshot needs to be consistent Non-distributed system needs to be quiescent Distributed system can use Chandy-Lamport algorithm, or some other algorithm, to obtain this
Example
File system auditing tools
Thought of as analyzing single state (snapshot) In reality, analyze many slices of different state unless file system quiescent Potential problem: if test at end depends on result of test at beginning, relevant parts of system state may have changed between the first test and the last
Classic TOCTTOU flaw
Transition-Based Auditing
Log information about action, and examine current state and proposed transition to determine if new state would be disallowed
Note: just analyzing the transition may not be enough; you may need the initial state Tend to use this when specific transitions always require analysis (for example, change of privilege)
Example
TCP access control mechanism intercepts TCP connections and checks against a list of connections to be blocked
Obtains IP address of source of connection Logs IP address, port, and result (allowed/blocked) in log file Purely transition-based (current state not analyzed at all)
Detect Known Violations of Policy

Goal: does a specific action and/or state that is known to violate security policy occur?
Assume that action automatically violates policy Policy may be implicit, not explicit Used to look for known attacks
November 1, 2004
Slide #1-898
Example
Land attack
Consider 3-way handshake to initiate TCP connection (next slide) What happens if source, destination ports and addresses the same? Host expects ACK(t+1), but gets ACK(s+1). RFC ambiguous:
p. 36 of RFC: send RST to terminate connection p. 69 of RFC: reply with empty packet having current sequence number t+1 and ACK number s+1but it receives packet and ACK number is incorrect. So it repeats this system hangs or runs very slowly, depending on whether interrupts are disabled
3-Way Handshake and Land

Source
ACK(s+1) SYN(t)
SYN(s)
ACK(t+1)
Destination
Normal: 1. srcseq = s, expects ACK s+1 2. destseq = t, expects ACK t+1; src gets ACK s+1 3. srcseq = s+1, destseq = t+1; dest gets ACK t+1 Land: 1. srcseq = destseq = s, expects ACK s+1 2. srcseq = destseq = t, expects ACK t+1 but gets ACK s+1 3. Never reached; recovery from error in 2 attempted
Slide #1-900
November 1, 2004
Detection
Must spot initial Land packet with source, destination addresses the same Logging requirement:
source port number, IP address destination port number, IP address
Auditing requirement:
If source port number = destination port number and source IP address = destination IP address, packet is part of a Land attack
November 1, 2004
Slide #1-901
Auditing Mechanisms
Systems use different mechanisms
Most common is to log all events by default, allow system administrator to disable logging that is unnecessary
Two examples
One audit system designed for a secure system One audit system designed for non-secure system
Secure Systems
Auditing mechanisms integrated into system design and implementation Security officer can configure reporting and logging:
To report specific events To monitor accesses by a subject To monitor accesses to an object
Controlled at audit subsystem

Irrelevant accesses, actions not logged
Example 1: VAX VMM

Designed to be a secure production system
Audit mechanism had to have minimal impact Audit mechanism had to be very reliable
Kernel is layered
Logging done where events of interest occur Each layer audits accesses to objects it controls
Audit subsystem processes results of logging from mechanisms in kernel

Audit subsystem manages system log Invoked by mechanisms in kernel
VAX VMM Audit Subsystem

Calls provide data to be logged
Identification of event, result Auxiliary data depending on event Callers name
Subsystem checks criteria for logging

If request matcher, data is logged Criteria are subject or object named in audit table, and severity level (derived from result) Adds date and time, other information
Other Issues
Always logged
Programmer can request event be logged Any attempt to violate policy
Protection violations, login failures logged when they occur repeatedly Use of covert channels also logged
Log filling up
Audit logging process signaled to archive log when log is 75% full If not possible, system stops
Example 2: CMW
Compartmented Mode Workstation designed to allow processing at different levels of sensitivity
Auditing subsystem keeps table of auditable events Entries indicate whether logging is turned on, what type of logging to use User level command chaud allows user to control auditing and what is audited
If changes affect subjects, objects currently being logged, the logging completes and then the auditable events are changed
November 1, 2004
Slide #1-907
CMW Process Control

System calls allow process to control auditing
audit_on turns logging on, names log filke audit_write validates log entry given as parameter, logs entry if logging for that entry is turned on audit_suspend suspends logging temporarily audit_resume resumes logging after suspension audit_off turns logging off for that process
System Calls
On system call, if auditing on:
System call recorded First 3 parameters recorded (but pointers not followed)
How audit_write works

If room in log, append new entry Otherwise halt system, discard new entry, or disable event that caused logging
Continue to try to log other events
Other Ways to Log

Problem: some processes want to log higher-level abstractions (application logging)
Window manager creates, writes high-level events to log Difficult to map low-level events into highlevel ones Disables low-level logging for window manager as unnecessary
CMW Auditing
Tool (redux) to analyze logged events Converts binary logs to printable format Redux allows user to constrain printing based on several criteria
Users Objects Security levels Events
November 1, 2004
Non-Secure Systems
Have some limited logging capabilities
Log accounting data, or data for non-security purposes Possibly limited security data like failed logins
Auditing subsystems focusing on security usually added after system completed

May not be able to log all events, especially if limited kernel modifications to support audit subsystem
Example: Basic Security Module

BSM enhances SunOS, Solaris security
Logs composed of records made up of tokens
Token contains information about event: user identity, groups, file system information, network, system call and result, etc. as appropriate
November 1, 2004
Slide #1-913
More About Records

Records refer to auditable events
Kernel events: opening a file Application events: failure to authenticate when logging in
Grouped into audit event classes based on events causing record generation
Before log created: tell system what to generate records for After log created: defined classes control which records given to analysis tools
Example Record
Logs are binary; this is from praudit
header , 35,AUE_EXIT,W ed Sep 18 11 : 35:28 1991, + 570000 msec, process , b ishop, r oot , roo t , daemon,1234, re tu rn ,Er ro r0 ,5 t ra i le r ,35
November 1, 2004
Slide #1-915
Auditing File Systems

Network File System (NFS)
Industry standard Server exports file system; client imports it Root of tree being exported called server mount point; place in client file tree where exported file system imported called client mount point
Logging and Auditing File System (LAFS)

Built on NFS
NFS Version 2
Mounting protocol
Client kernel contacts servers mount daemon Daemon checks client is authorized to mount file system Daemon returns file handle pointing to server mount point Client creates entry in client file system corresponding to file handle Access restrictions enforced
On client side: server not aware of these On server side: client not aware of these
File Access Protocol

Process tries to open file as if it were local Client kernel sends file handle for element of path referring to remote file to servers NFS server using LOOKUP request If file handle valid, server replies with appropriate file handle Client requests attributes with GETATTR
Client then determines if access allowed; if not, denies
Iterate above three steps until handle obtained for requested file
Or access denied by client
Other Important Details

NFS stateless
Server has no idea which files are being accessed and by whom
NFS access control

Most servers require requests to come from privileged programs
Check that source port is 1023 or less
Underlying messages identify user

To some degree of certainty
Site Policy
1. NFS servers respond only to authorized clients 2. UNIX access controls regulate access to servers exported file system 3. No client host can access a non-exported file system
November 1, 2004
Slide #1-920
Resulting Constraints
1. File access granted client authorized to import file system, user can search all parent directories, user can access file as requested, file is descendent of servers file system mount point
From P1, P2, P3
2. Device file created or file type changed to device users UID is 0

From P2; only UID 0 can do these actions
November 1, 2004
Slide #1-921
More Constraints
3. Possession of file handle file handle issued to user
From P1, P2; otherwise unauthorized client could access files in forbidden ways
4. Operation succeeds similar local operation would succeed

From P2; mount should fail if requester UID not 0
November 1, 2004
Slide #1-922
NFS Operations
Transitions from secure to non-secure state can occur only when NFS command occurs Example commands:
MOUNT filesystem
Mount the named file system on the requesting client, if allowed
LOOKUP dir_handle file_name

Search in directory with handle dir_handle for file named file_name; return file handle for file_name
Logging Requirements
1.When file handle issued, server records handle, UID and GID of user requesting it, client host making request
Similar to allocating file descriptor when file opened; allows validation of later requests
2.When file handle used as parameter, server records UID, GID of user
Was user using file handle issued that file handleuseful for detecting spoofs
Logging Requirements
3. When file handle issued, server records relevant attributes of containing object
On LOOKUP, attributes of containing directory show whether it can be searched
4. Record results of each operation

Lets auditor determine result
5. Record file names used as arguments

Reconstruct path names, purpose of commands
Audit Criteria: MOUNT

MOUNT
Check that MOUNT server denies all requests by unauthorized clients to import file system that host exports
Obtained from constraints 1, 4 Log requirements 1 (who requests it), 3 (access attributesto whom can it be exported), 4 (result)
November 1, 2004
Slide #1-926
Audit Criteria: LOOKUP

2. Check file handle comes from client, user to which it was issued
Obtained from constraint 3 Log requirement 1 (who issued to), 2 (who is using)
3. Check that directory has file system mount point as ancestor and user has search permission on directory
Obtained from constraint 1 Log requirements 2 (who is using handle), 3 (owner, group, type, permissions of object), 4 (result), 5 (reconstruct path name)
LAFS
File system that records user level activities Uses policy-based language to automate checks for violation of policies Implemented as extension to NFS
You create directory with lmkdir and attach policy with lattach:
lmkd i r/ usr /home/xyzzy /pro j ect po l i cy l a t tach /us r /home/xyzzy /pro j ect/ la f s /xyzzy/p ro jec t
LAFS Components
Name server File manager Configuration assistant
Sets up required protection modes; interacts with name server, underlying file protection mechanisms
Audit logger
Logs file accesses; invoked whenever process accesses file
Policy checker
Validates policies, checks logs conform to policy
How It Works
No changes to applications Each file has 3 associated virtual files
file%log: all accesses to file file%policy: access control policy for file file%audit: when accessed, triggers audit in which accesses are compared to policy for file
Virtual files not shown in listing

LAFS knows the extensions and handles them properly
Example Policies
proh ib i t :0900-1700:* : * :wumpus:exec
No-one can execute wumpus between 9AM and 5PM

a l low:* : Makef i l e:* :make: read a l low:* : Makef i l e:Owner :makedepend:wr i te a l low:* : * .o , * .out :Owner ,Group:gcc , ld : wr i te a l low: 010929: * .c , * .h : O wner : emacs,v i ,ed :wr i te
Program make can read Makefile Owner can change Makefile using makedepend Owner, group member can create .o, .out files using gcc and ld Owner can modify .c, .h files using named editors up to Sep. 29, 2001
Comparison
Security policy controls access
Goal is to detect, report violations Auditing mechanisms built in
LAFS stacked onto NFS

If you access files not through LAFS, access not recorded
NFS auditing at lower layer

So if you use NFS, accesses recorded
Comparison
Users can specify policies in LAFS
Use %policy file
NFS policy embedded, not easily changed

It would be set by site, not users
Which is better?
Depends on goal; LAFS is more flexible but easier to evade. Use both together, perhaps?
Audit Browsing
Goal of browser: present log information in a form easy to understand and use Several reasons to do this:
Audit mechanisms may miss problems that auditors will spot Mechanisms may be unsophisticated or make invalid assumptions about log format or meaning Logs usually not integrated; often different formats, syntax, etc.
Browsing Techniques
Text display
Does not indicate relationships between events
Hypertext display
Indicates local relationships between events Does not indicate global relationships clearly
Relational database browsing

DBMS performs correlations, so auditor need not know in advance what associations are of interest Preprocessing required, and may limit the associations DBMS can make
More Browsing Techniques

Replay
Shows events occurring in order; if multiple logs, intermingles entries
Graphing
Nodes are entities, edges relationships Often too cluttered to show everything, so graphing selects subsets of events
Slicing
Show minimum set of log events affecting object Focuses on local relationships, not global ones
Example: Visual Audit Browser

Frame Visualizer
Generates graphical representation of logs
Movie Maker
Generates sequence of graphs, each event creating a new graph suitably modified
Hypertext Generator
Produces page per user, page per modified file, summary and index pages
Focused Audit Browser

Enter node name, displays node, incident edges, and nodes at end of edges
Example Use
File changed
Use focused audit browser
Changed file is initial focus Edges show which processes have altered file
Focus on suspicious process

Iterate through nodes until method used to gain access to system determined
Question: is masquerade occurring?

Auditor knows audit UID of attacker
Tracking Attacker
Use hypertext generator to get all audit records with that UID
Now examine them for irregular activity Frame visualizer may help here Once found, work forward to reconstruct activity
For non-technical people, use movie maker to show what happened

Helpful for law enforcement authorities especially!
Example: MieLog
Computes counts of single words, word pairs
Auditor defines threshold count MieLog colors data with counts higher than threshold
Display uses graphics and text together

Tag appearance frequency area: colored based on frequency (e.g., red is rare) Time information area: bar graph showing number of log entries in that period of time; click to get entries Outline of message area: outline of log messages, colored to match tag appearance frequency area Message in text area: displays log entry under study
Example Use
Auditor notices unexpected gap in time information area
No log entries during that time!?!?
Auditor focuses on log entries before, after gap

Wants to know why logging turned off, then turned back on
Color of words in entries helps auditor find similar entries elsewhere and reconstruct patterns
Key Points
Logging is collection and recording; audit is analysis Need to have clear goals when designing an audit system Auditing should be designed into system, not patched into system after it is implemented Browsing through logs helps auditors determine completeness of audit (and effectiveness of audit mechanisms!)
Chapter 22: Intrusion Detection

Principles Basics Models of Intrusion Detection Architecture of an IDS Organization Incident Response
November 1, 2004
Principles of Intrusion Detection

Characteristics of systems not under attack
User, process actions conform to statistically predictable pattern User, process actions do not include sequences of actions that subvert the security policy Process actions correspond to a set of specifications describing what the processes are allowed to do
Systems under attack do not meet at least one of these

Example
Goal: insert a back door into a system
Intruder will modify system configuration file or program Requires privilege; attacker enters system as an unprivileged user and must acquire privilege
Nonprivileged user may not normally acquire privilege (violates #1) Attacker may break in using sequence of commands that violate security policy (violates #2) Attacker may cause program to act in ways that violate programs specification
Basic Intrusion Detection

Attack tool is automated script designed to violate a security policy Example: rootkit
Includes password sniffer Designed to hide itself using Trojaned versions of various programs (ps, ls, find, netstat, etc.) Adds back doors (login, telnetd, etc.) Has tools to clean up log entries (zapper, etc.)
Detection
Rootkit configuration files cause ls, du, etc. to hide information
ls lists all files in a directory
Except those hidden by configuration file
dirdump (local program to list directory entries) lists them too

Run both and compare counts If they differ, ls is doctored
Other approaches possible

Key Point
Rootkit does not alter kernel or file structures to conceal files, processes, and network connections
It alters the programs or system calls that interpret those structures Find some entry point for interpretation that rootkit did not alter The inconsistency is an anomaly (violates #1)
Dennings Model
Hypothesis: exploiting vulnerabilities requires abnormal use of normal commands or instructions
Includes deviation from usual actions Includes execution of actions leading to breakins Includes actions inconsistent with specifications of privileged programs
Goals of IDS
Detect wide variety of intrusions
Previously known and unknown attacks Suggests need to learn/adapt to new attacks or changes in behavior
Detect intrusions in timely fashion

May need to be be real-time, especially when system responds to intrusion
Problem: analyzing commands may impact response time of system
May suffice to report intrusion occurred a few minutes or hours ago

Goals of IDS
Present analysis in simple, easy-to-understand format
Ideally a binary indicator Usually more complex, allowing analyst to examine suspected attack User interface critical, especially when monitoring many systems
Be accurate
Minimize false positives, false negatives Minimize time spent verifying attacks, looking for them
Models of Intrusion Detection

Anomaly detection
What is usual, is known What is unusual, is bad
Misuse detection
What is bad, is known What is not bad, is good
Specification-based detection
What is good, is known What is not good, is bad
Anomaly Detection
Analyzes a set of characteristics of system, and compares their values with expected values; report when computed statistics do not match expected statistics
Threshold metrics Statistical moments Markov model
Threshold Metrics
Counts number of events that occur
Between m and n events (inclusive) expected to occur If number falls outside this range, anomalous
Example
Windows: lock user out after k failed sequential login attempts. Range is (0, k1).
k or more failed logins deemed anomalous
Difficulties
Appropriate threshold may depend on nonobvious factors
Typing skill of users If keyboards are US keyboards, and most users are French, typing errors very common
Dvorak vs. non-Dvorak within the US
November 1, 2004
Slide #1-955
Statistical Moments
Analyzer computes standard deviation (first two moments), other measures of correlation (higher moments)
If measured values fall outside expected interval for particular moments, anomalous
Potential problem
Profile may evolve over time; solution is to weigh data appropriately or alter rules to take changes into account
Example: IDES
Developed at SRI International to test Dennings model
Represent users, login session, other entities as ordered sequence of statistics <q0,j, , qn,j> qi,j (statistic i for day j) is count or time interval Weighting favors recent behavior over past behavior
Ak,j sum of counts making up metric of kth statistic on jth day qk,l+1 = Ak,l+1 Ak,l + 2rtqk,l where t is number of log entries/total time since start, r factor determined through experience
November 1, 2004
Slide #1-957
Potential Problems
Assumes behavior of processes and users can be modeled statistically
Ideal: matches a known distribution such as Gaussian or normal Otherwise, must use techniques like clustering to determine moments, characteristics that show anomalies, etc.
Real-time computation a problem too

Markov Model
Past state affects current transition Anomalies based upon sequences of events, and not on occurrence of single event Problem: need to train system to establish valid sequences
Use known, training data that is not anomalous The more training data, the better the model Training data should cover all possible normal uses of system
Example: TIM
Time-based Inductive Learning Sequence of events is abcdedeabcabc TIM derives following rules:
R1: abc (1.0) R4: de (1.0) R2: cd (0.5) R5: ea (0.5) R3: ce (0.5) R6: ed (0.5)
Seen: abd; triggers alert

c always follows ab in rule set
Seen: acf; no alert as multiple events can follow c

May add rule R7: cf (0.33); adjust R2, R3
Misuse Modeling
Determines whether a sequence of instructions being executed is known to violate the site security policy
Descriptions of known or potential exploits grouped into rule sets IDS matches data against rule sets; on success, potential attack found
Cannot detect attacks unknown to developers of rule sets

No rules to cover them
Example: NFR
Built to make adding new rules easily Architecture:
Packet sucker: read packets from network Decision engine: uses filters to extract information Backend: write data generated by filters to disk
Query backend allows administrators to extract raw, postprocessed data from this file Query backend is separate from NFR process
N-Code Language
Filters written in this language Example: ignore all traffic not intended for 2 web servers:
#l i s to f my web servers my_web_servers = [ 10 .237.100.189 10. 237.55. 93 ]; # we assume a l l HTTP t r af f i ci s on por t 80 f i l te r watch tcp ( c l ien t , dpor t :80 ) { i f( ip .dest!= my_web_servers) re tu rn ; # now process the packet; we jus t wr i te out packet i n fo record sys tem. t i me, ip .src ,ip .des tto www._ l i s t ; } w w w_l ist = recorder ( log)
Specification Modeling
Determines whether execution of sequence of instructions violates specification Only need to check programs that alter protection state of system
November 1, 2004
Slide #1-964
System Traces
Notion of subtrace (subsequence of a trace) allows you to handle threads of a process, process of a system Notion of merge of traces U, V when trace U and trace V merged into single trace Filter p maps trace T to subtrace T such that, for all events ti T, p(ti) is true
Example: Apply to rdist

Ko, Levitt, Ruschitzka defined PE-grammar to describe accepted behavior of program rdist creates temp file, copies contents into it, changes protection mask, owner of it, copies it into place
Attack: during copy, delete temp file and place symbolic link with same name as temp file rdist changes mode, ownership to that of program
November 1, 2004
Slide #1-966
Relevant Parts of Spec

Specification of chmod, chown says that they can only alter attributes of files that rdist creates Chown, chmod of symlink violates this rule as M.newownerid U (owner of file symlink points to is not owner of file rdist is distributing)
November 1, 2004
Slide #1-967
Comparison and Contrast

Misuse detection: if all policy rules known, easy to construct rulesets to detect violations
Usual case is that much of policy is unspecified, so rulesets describe attacks, and are not complete
Anomaly detection: detects unusual events, but these are not necessarily security problems Specification-based vs. misuse: spec assumes if specifications followed, policy not violated; misuse assumes if policy as embodied in rulesets followed, policy not violated
IDS Architecture
Basically, a sophisticated audit system
Agent like logger; it gathers data for analysis Director like analyzer; it analyzes data obtained from the agents according to its internal rules Notifier obtains results from director, and takes some action
May simply notify security officer May reconfigure agents, director to alter collection, analysis methods May activate response mechanism
Agents
Obtains information and sends to director May put information into another form
Preprocessing of records to extract relevant parts
May delete unneeded information Director may request agent send other information
Example
IDS uses failed login attempts in its analysis Agent scans login log every 5 minutes, sends director for each new login attempt:
Time of failed login Account name and entered password
Director requests all records of login (failed or not) for particular user
Suspecting a brute-force cracking attempt
Host-Based Agent
Obtain information from logs
May use many logs as sources May be security-related or not May be virtual logs if agent is part of the kernel
Very non-portable
Agent generates its information

Scans information needed by IDS, turns it into equivalent of log record Typically, check policy; may be very complex
Network-Based Agents
Detects network-oriented attacks
Denial of service attack introduced by flooding a network
Monitor traffic for a large number of hosts Examine the contents of the traffic itself Agent must have same view of traffic as destination
TTL tricks, fragmentation may obscure this
End-to-end encryption defeats content monitoring

Not traffic analysis, though
Network Issues
Network architecture dictates agent placement
Ethernet or broadcast medium: one agent per subnet Point-to-point medium: one agent per connection, or agent at distribution/routing point
Focus is usually on intruders entering network

If few entry points, place network agents behind them Does not help if inside attacks to be monitored
November 1, 2004
Slide #1-974
Aggregation of Information
Agents produce information at multiple layers of abstraction
Application-monitoring agents provide one view (usually one line) of an event System-monitoring agents provide a different view (usually many lines) of an event Network-monitoring agents provide yet another view (involving many network packets) of an event
Director
Reduces information from agents
Eliminates unnecessary, redundant records
Analyzes remaining information to determine if attack under way

Analysis engine can use a number of techniques, discussed before, to do this
Usually run on separate system

Does not impact performance of monitored systems Rules, profiles not available to ordinary users
Example
Jane logs in to perform system maintenance during the day She logs in at night to write reports One night she begins recompiling the kernel Agent #1 reports logins and logouts Agent #2 reports commands executed
Neither agent spots discrepancy Director correlates log, spots it at once
Adaptive Directors
Modify profiles, rule sets to adapt their analysis to changes in system
Usually use machine learning or planning to determine how to do this
Example: use neural nets to analyze logs

Network adapted to users behavior over time Used learning techniques to improve classification of events as anomalous
Reduced number of false alarms
Notifier
Accepts information from director Takes appropriate action
Notify system security officer Respond to attack
Often GUIs
Well-designed ones use visualization to convey information
GrIDS GUI
D B A C E
GrIDS interface showing the progress of a worm as it spreads through network Left is early in spread Right is later on
Other Examples
Courtney detected SATAN attacks
Added notification to system log Could be configured to send email or paging message to system administrator
IDIP protocol coordinates IDSes to respond to attack

If an IDS detects attack over a network, notifies other IDSes on co-operative firewalls; they can then reject messages from the source
Organization of an IDS
Monitoring network traffic for intrusions
NSM system
Combining host and network monitoring

DIDS
Making the agents autonomous

AAFID system
November 1, 2004
Slide #1-982
Monitoring Networks: NSM

Develops profile of expected usage of network, compares current usage Has 3-D matrix for data
Axes are source, destination, service Each connection has unique connection ID Contents are number of packets sent over that connection for a period of time, and sum of data NSM generates expected connection data Expected data masks data in matrix, and anything left over is reported as an anomaly
Problem
Too much data!
S1 Solution: arrange data hierarchically into groups (S1, D2)
Construct by folding axes of matrix
(S1, D1)
(S1, D1, SMTP) (S1, D2, SMTP) (S1, D1, FTP) (S1, D2, FTP)
November 1, 2004
Analyst could expand any group flagged as anomalous
Slide #1-984
Signatures
Analyst can write rule to look for specific occurrences in matrix
Repeated telnet connections lasting only as long as set-up indicates failed login attempt
Analyst can write rules to match against network traffic

Used to look for excessive logins, attempt to communicate with non-existent host, single host communicating with 15 or more hosts
Other
Graphical interface independent of the NSM matrix analyzer Detected many attacks
But false positives too
Still in use in some places

Signatures have changed, of course
Also demonstrated intrusion detection on network is feasible

Did no content analysis, so would work even with encrypted connections
Combining Sources: DIDS

Neither network-based nor host-based monitoring sufficient to detect some attacks
Attacker tries to telnet into system several times using different account names: network-based IDS detects this, but not host-based monitor Attacker tries to log into system using an account without password: host-based IDS detects this, but not network-based monitor
DIDS uses agents on hosts being monitored, and a network monitor

DIDS director uses expert system to analyze data
Attackers Moving in Network

Intruder breaks into system A as alice Intruder goes from A to system B, and breaks into Bs account bob Host-based mechanisms cannot correlate these DIDS director could see bob logged in over alices connection; expert system infers they are the same user
Assigns network identification number NID to this user
Handling Distributed Data

Agent analyzes logs to extract entries of interest
Agent uses signatures to look for attacks
Summaries sent to director
Other events forwarded directly to director
DIDS model has agents report:

Events (information in log entries) Action, domain
Actions and Domains

Subjects perform actions
session_start, session_end, read, write, execute, terminate, create, delete, move, change_rights, change_user_id
Domains characterize objects

tagged, authentication, audit, network, system, sys_info, user_info, utility, owned, not_owned Objects put into highest domain to which it belongs
Tagged, authenticated file is in domain tagged Unowned network object is in domain network
More on Agent Actions

Entities can be subjects in one view, objects in another
Process: subject when changes protection mode of object, object when process is terminated Table determines which events sent to DIDS director Based on actions, domains associated with event All NIDS events sent over so director can track view of system
Action is session_start or execute; domain is network
Layers of Expert System Model

1. Log records 2. Events (relevant information from log entries) 3. Subject capturing all events associated with a user; NID assigned to this subject 4. Contextual information such as time, proximity to other events
Sequence of commands to show who is using the system Series of failed logins follow
Top Layers
5. Network threats (combination of events in context)
Abuse (change to protection state) Misuse (violates policy, does not change state) Suspicious act (does not violate policy, but of interest)
6. Score (represents security state of network)

Derived from previous layer and from scores associated with rules
Analyst can adjust these scores as needed
A convenience for user

Autonomous Agents: AAFID

Distribute director among agents Autonomous agent is process that can act independently of the system of which it is part Autonomous agent performs one particular monitoring function
Has its own internal model Communicates with other agents Agents jointly decide if these constitute a reportable intrusion
Advantages
No single point of failure
All agents can act as director In effect, director distributed over all agents
Compromise of one agent does not affect others Agent monitors one resource
Small and simple
Agents can migrate if needed Approach appears to be scalable to large networks

Disadvantages
Communications overhead higher, more scattered than for single director
Securing these can be very hard and expensive
As agent monitors one resource, need many agents to monitor multiple resources Distributed computation involved in detecting intrusions
This computation also must be secured
Example: AAFID
Host has set of agents and transceiver
Transceiver controls agent execution, collates information, forwards it to monitor (on local or remote system)
Filters provide access to monitored resources

Use this approach to avoid duplication of work and system dependence Agents subscribe to filters by specifying records needed Multiple agents may subscribe to single filter
Transceivers and Monitors

Transceivers collect data from agents
Forward it to other agents or monitors Can terminate, start agents on local system
Example: System begins to accept TCP connections, so transceiver turns on agent to monitor SMTP
Monitors accept data from transceivers

Can communicate with transceivers, other monitors
Send commands to transceiver
Perform high level correlation for multiple hosts If multiple monitors interact with transceiver, AAFID must ensure transceiver receives consistent commands
Other
User interface interacts with monitors
Could be graphical or textual
Prototype implemented in PERL for Linux and Solaris

Proof of concept Performance loss acceptable
November 1, 2004
Slide #1-999
Incident Prevention
Identify attack before it completes Prevent it from completing Jails useful for this
Attacker placed in a confined environment that looks like a full, unrestricted environment Attacker may download files, but gets bogus ones Can imitate a slow system, or an unreliable one Useful to figure out what attacker wants MLS systems provide natural jails
Intrusion Handling
Restoring system to satisfy site security policy Six phases
Preparation for attack (before attack detected) Identification of attack Containment of attack (confinement) Eradication of attack (stop attack) Recovery from attack (restore system to secure state) Follow-up to attack (analysis and other actions)
Discussed in what follows

Containment Phase
Goal: limit access of attacker to system resources Two methods
Passive monitoring Constraining access
November 1, 2004
Slide #1-1002
Passive Monitoring
Records attackers actions; does not interfere with attack
Idea is to find out what the attacker is after and/or methods the attacker is using
Problem: attacked system is vulnerable throughout

Attacker can also attack other systems
Example: type of operating system can be derived from settings of TCP and IP packets of incoming connections
Analyst draws conclusions about source of attack
Constraining Actions
Reduce protection domain of attacker Problem: if defenders do not know what attacker is after, reduced protection domain may contain what the attacker is after
Stoll created document that attacker downloaded Download took several hours, during which the phone call was traced to Germany
Deception
Deception Tool Kit
Creates false network interface Can present any network configuration to attackers When probed, can return wide range of vulnerabilities Attacker wastes time attacking non-existent systems while analyst collects and analyzes attacks to determine goals and abilities of attacker Experiments show deception is effective response to keep attackers from targeting real systems
Eradication Phase
Usual approach: deny or remove access to system, or terminate processes involved in attack Use wrappers to implement access control
Example: wrap system calls
On invocation, wrapper takes control of process Wrapper can log call, deny access, do intrusion detection Experiments focusing on intrusion detection used multiple wrappers to terminate suspicious processes
Example: network connections

Wrapper around servers log, do access control on, incoming connections and control access to Web-based databases
Firewalls
Mediate access to organizations network
Also mediate access out to the Internet
Example: Java applets filtered at firewall

Use proxy server to rewrite them
Change <applet> to something else
Discard incoming web files with hex sequence CA FE BA BE

All Java class files begin with this
Block all files with name ending in .class or .zip

Lots of false positives
Intrusion Detection and Isolation Protocol

Coordinates reponse to attacks Boundary controller is system that can block connection from entering perimeter
Typically firewalls or routers
Neighbor is system directly connected IDIP domain is set of systems that can send messages to one another without messages passing through boundary controller
Protocol
IDIP protocol engine monitors connection passing through members of IDIP domains
If intrusion observed, engine reports it to neighbors Neighbors propagate information about attack Trace connection, datagrams to boundary controllers Boundary controllers coordinate responses
Usually, block attack, notify other controllers to block relevant communications
November 1, 2004
Slide #1-1009
Example
C b A a W X Y Z f D e
C, D, W, X, Y, Z boundary controllers f launches flooding attack on A Note after X xuppresses traffic intended for A, W begins accepting it and A, b, a, and W can freely communicate again
Follow-Up Phase
Take action external to system against attacker
Thumbprinting: traceback at the connection level IP header marking: traceback at the packet level Counterattacking
November 1, 2004
Slide #1-1011
Counterattacking
Use legal procedures
Collect chain of evidence so legal authorities can establish attack was real Check with lawyers for this
Rules of evidence very specific and detailed If you dont follow them, expect case to be dropped
Technical attack
Goal is to damage attacker seriously enough to stop current attack and deter future attacks
Consequences
1. May harm innocent party
Attacker may have broken into source of attack or may be impersonating innocent party
2. May have side effects

If counterattack is flooding, may block legitimate use of network
3. Antithetical to shared use of network

Counterattack absorbs network resources and makes threats more immediate
4. May be legally actionable

Example: Counterworm
Counterworm given signature of real worm
Counterworm spreads rapidly, deleting all occurrences of original worm
Some issues
How can counterworm be set up to delete only targeted worm? What if infected system is gathering worms for research? How do originators of counterworm know it will not cause problems for any system?
And are they legally liable if it does?
Key Points
Intrusion detection is a form of auditing Anomaly detection looks for unexpected events Misuse detection looks for what is known to be bad Specification-based detection looks for what is known not to be good Intrusion response requires careful thought and planning
Chapter 23: Network Security

Introduction to the Drib Policy Development Network Organization Availability Anticipating Attacks
November 1, 2004
Slide #1-1016
Introduction
Goal: apply concepts, principles, mechanisms discussed earlier to a particular situation
Focus here is on securing network Begin with description of company Proceed to define policy Show how policy drives organization
November 1, 2004
The Drib
Builds and sells dribbles Developing network infrastructure allowing it to connect to Internet to provide mail, web presence for consumers, suppliers, other partners
November 1, 2004
Slide #1-1018
Specific Problems
Internet presence required
E-commerce, suppliers, partners Drib developers need access External users cannot access development sites
Hostile takeover by competitor in progress

Lawyers, corporate officers need access to development data Developers cannot have access to some corporate data
November 1, 2004
Slide #1-1019
Goals of Security Policy

Data related to company plans to be kept secret
Corporate data such as what new products are being developed is known on a need-to-know basis only
When customer supplies data to buy a dribble, only folks who fill the order can access that information
Company analysts may obtain statistics for planning
Lawyers, company officials must approve release of any sensitive data

Policy Development
Policy: minimize threat of data being leaked to unauthorized entities Environment: 3 internal organizations
Customer Service Group (CSG)
Maintains customer data Interface between clients, other internal organizations
Development Group (DG)

Develops, modifies, maintains products Relies on CSG for customer feedback
Corporate Group (CG)

Handles patents, lawsuits, etc.
Nature of Information Flow

Public
Specs of current products, marketing literature
CG, DG share info for planning purposes

Problems, patent applications, budgets, etc.
Private
CSG: customer info like credit card numbers CG: corporate info protected by attorney privilege DG: plans, prototypes for new products to determine if production is feasible before proposing them to CG
Data Classes
Public data (PD): available to all Development data for existing products (DDEP): available to CG, DG only Development data for future products (DDFP): available to DG only Corporate data (CpD): available to CG only Customer data (CuD): available to CSG only
Data Class Changes

DDFP DDEP: as products implemented DDEP PD: when deemed advantageous to publicize some development details
For marketing purposes, for example
CpD PD: as privileged info becomes public through mergers, lawsiut filings, etc. Note: no provision for revealing CuD directly
This protects privacy of Dribs customers
User Classes
Outsiders (O): members of public
Access to public data Can also order, download drivers, send email to company
Developers (D): access to DDEP, DDFP

Cannot alter development data for existing products
Corporate executives (C): access to CD

Can read DDEP, DDFP, CuD but not alter them Sometimes can make sensitive data public
Employees (E): access to CuD only

Access Control Matrix for Policy

O PD DDEP DDFP CpD CuD
November 1, 2004
D r r r, w r r r
C r
r, w w r
r, w
Slide #1-1026
r is read right, w is write right
Type of Policy
Mandatory policy
Members of O, D, C, E cannot change permissions to allow members of another user class to access data
Discretionary component
Within each class, individuals may have control over access to files they own View this as an issue internal to each group and not of concern at corporate policy level
At corporate level, discretionary component is allow always
Reclassification of Data
Who must agree for each?
C, D must agree for DDFP DDEP C, E must agree for DDEP PD C can do CpD PD
But two members of C must agree to this
Separation of privilege met

At least two different people must agree to the reclassification When appropriate, the two must come from different user classes
Availability
Drib world-wide multinational corp
Does business on all continents
Imperative anyone be able to contact Drib at any time

Drib places very high emphasis on customer service Requirement: Dribs systems be available 99% of the time
1% allowed for planned maintenance, unexpected downtime
November 1, 2004
Slide #1-1029
Consistency Check: Goal 1

Goal 1: keep sensitive info confidential
Developers
Need to read DDEP, DDFP, and to alter DDFP No need to access CpD, CuD as dont deal with customers or decide which products to market
Corporate executives
Need to read, alter CpD, and read DDEP
This matches access permissions


Goal 2: only employees who handle purchases can access customer data, and only they and customer can alter it
Outsiders
Need to alter CuD, do not need to read it
Customer support
Need to read, alter CuD
This matches access permissions


Goal 3: releasing sensitive info requires corporate approval
Corporate executives
Must approve any reclassification No-one can write to PD, except through reclassification
This matches reclassification constraints

Consistency Check: Transitive Closure

O PD DDEP DDFP CpD CuD
November 1, 2004
D r r r, w w r r r
C r
r, w r
w r, w
Slide #1-1033
r is read right, w is write right

Interpretation
From transitive closure:
Only way for data to flow into PD is by reclassification Key point of trust: members of C By rules for moving data out of DDEP, DDFP, someone other than member of C must also approve
Satisfies separation of privilege
Conclusion: policy is consistent

Network Organization
Partition network into several subnets
Guards between them prevent leaks
Internet Outer firewall DMZ Web server INTERNAL Corporate data subnet Customer data subnet Mail serv er DNS server Inner firewall Internal DNS server Development subnet Internal mail server
November 1, 2004
Slide #1-1035
DMZ
Portion of network separating purely internal network from external network
Allows control of accesses to some trusted systems inside the corporate perimeter If DMZ systems breached, internal systems still safe Can perform different types of checks at boundary of internal,DMZ networks and DMZ,Internet network
Firewalls
Host that mediates access to a network
Allows, disallows accesses based on configuration and type of access
Example: block Back Orifice

BO allows external users to control systems
Requires commands to be sent to a particular port (say, 25345)
Firewall can block all traffic to or from that port

November 1, 2004
So even if BO installed, outsiders cant use it

Slide #1-1037
Filtering Firewalls
Access control based on attributes of packets and packet headers
Such as destination address, port numbers, options, etc. Also called a packet filtering firewall Does not control access based on content Examples: routers, other infrastructure systems
Proxy
Intermediate agent or server acting on behalf of endpoint without allowing a direct connection between the two endpoints
So each endpoint talks to proxy, thinking it is talking to other endpoint Proxy decides whether to forward messages, and whether to alter them
November 1, 2004
Slide #1-1039
Proxy Firewall
Access control done with proxies
Usually bases access control on content as well as source, destination addresses, etc. Also called an applications level or application level firewall Example: virus checking in electronic mail
Incoming mail goes to proxy firewall Proxy firewall receives mail, scans it If no virus, mail forwarded to destination If virus, mail rejected or disinfected before forwarding
November 1, 2004
Views of a Firewall
Access control mechanism
Determines which traffic goes into, out of network
Audit mechanism
Analyzes packets that enter Takes action based upon the analysis
Leads to traffic shaping, intrusion response, etc.
November 1, 2004
Slide #1-1041
Analysis of Drib Network

Security policy: public entities on outside but may need to access corporate resources
Those resources provided in DMZ
No internal system communicates directly with systems on Internet

Restricts flow of data to public For data to flow out, must pass through DMZ
Firewalls, DMZ are pump
Implementation
Conceal all internal addresses
Make them all on 10., 172., or 192.168. subnets
Inner firewall uses NAT to map addresses to firewalls address
Give each host a non-private IP address

Inner firewall never allows those addresses to leave internal network
Easy as all services are proxied by outer firewall

Email is a bit tricky
November 1, 2004
Slide #1-1043
Email
Problem: DMZ mail server must know address in order to send mail to internal destination
Could simply be distinguished address that causes inner firewall to forward mail to internal mail server
Internal mail server needs to know DMZ mail server address

Same comment
DMZ Web Server

In DMZ so external customers can access it without going onto internal network
If data needs to be sent to internal network (such as for an order), transmission is made separately and not as part of transaction
November 1, 2004
Slide #1-1045
Application of Principles
Least privilege
Containment of internal addresses
Complete mediation
Inner firewall mediates every access to DMZ
Separation of privilege
Going to Internet must pass through inner, outer firewalls and DMZ servers
Application of Principles
Least common mechanism
Inner, outer firewalls distinct; DMZ servers separate from inner servers DMZ DNS violates this principle
If it fails, multiple systems affected Inner, outer firewall addresses fixed, so they do not depend on DMZ DNS
November 1, 2004
Slide #1-1047
Outer Firewall Configuration

Goals: restrict public access to corporate network; restrict corporate access to Internet Required: public needs to send, receive email; access web services
So outer firewall allows SMTP, HTTP, HTTPS Outer firewall uses its address for those of mail, web servers
Details
Proxy firewall SMTP: mail assembled on firewall
Scanned for malicious logic; dropped if found Otherwise forwarded to DMZ mail server
HTTP, HTTPS: messages checked

Checked for suspicious components like very long lines; dropped if found Otherwise, forwarded to DMZ web server
Note: web, mail servers different systems

Neither same as firewall
Attack Analysis
Three points of entry for attackers:
Web server ports: proxy checks for invalid, illegal HTTP, HTTPS requests, rejects them Mail server port: proxy checks email for invalid, illegal SMTP requests, rejects them Bypass low-level firewall checks by exploiting vulnerabilities in software, hardware
Firewall designed to be as simple as possible Defense in depth
Defense in Depth
Form of separation of privilege To attack system in DMZ by bypassing firewall checks, attacker must know internal addresses
Then can try to piggyback unauthorized messages onto authorized packets
But the rewriting of DMZ addresses prevents this

Inner Firewall Configuration

Goals: restrict access to corporate internal network Rule: block all traffic except for that specifically authorized to enter
Principle of fail-safe defaults
Example: Drib uses NFS on some internal systems

Outer firewall disallows NFS packets crossing Inner firewall disallows NFS packets crossing, too
DMZ does not need access to this information (least privilege) If inner firewall fails, outer one will stop leaks, and vice versa (separation of privilege)
More Configuration
Internal folks require email
SMTP proxy required
Administrators for DMZ need login access

So, allow SSH through provided:
Destination is a DMZ server Originates at specific internal host (administrative host)
Violates least privilege, but ameliorated by above
DMZ DNS needs to know address of administrative host

More on this later
DMZ
Look at servers separately:
Web server: handles web requests with Internet
May have to send information to internal network
Email server: handles email with Internet

Must forward email to internal mail server
DNS
Used to provide addresses for systems DMZ servers talk to
Log server
DMZ systems log info here
November 1, 2004
Slide #1-1054
DMZ Mail Server

Performs address, content checking on all email Goal is to hide internal information from outside, but be transparent to inside Receives email from Internet, forwards it to internal network Receives email from internal network, forwards it to Internet
Mail from Internet

Reassemble messages into header, letter, attachments as files Scan header, letter, attachments looking for bad content
Bad = known malicious logic If none, scan original letter (including attachments and header) for violation of SMTP spec
Scan recipient address lines

Address rewritten to direct mail to internal mail server Forward letter there
Mail to Internet
Like mail from Internet with 2 changes:
Step 2: also scan for sensitive data (like proprietary markings or content, etc.) Step 3: changed to rewrite all header lines containing host names, email addresses, and IP addresses of internal network
All are replaced by drib.org or IP address of external firewall
Administrative Support
Runs SSH server
Configured to accept connections only from trusted administrative host in internal network All public keys for that host fixed; no negotiation to obtain those keys allowed Allows administrators to configure, maintain DMZ mail host remotely while minimizing exposure of host to compromise
DMZ Web Server

Accepts, services requests from Internet Never contacts servers, information sources in internal network CGI scripts checked for potential attacks
Hardened to prevent attacks from succeeding Server itself contains no confidential data
Server is www.drib.org and uses IP address of outer firewall when it must supply one
Updating DMZ Web Server

Clone of web server kept on internal network
Called WWW-clone
All updates done to WWW-clone

Periodically admins copy contents of WWW-clone to DMZ web server
DMZ web server runs SSH server

Used to do updates as well as maintenance, configuration Secured like that of DMZ mail server
Internet Ordering
Orders for Drib merchandise from Internet
Customer enters data, which is saved to file After user confirms order, web server checks format, content of file and then uses public key of system on internal customer subnet to encipher it
This file is placed in a spool area not accessible to web server program
Original file deleted Periodically, internal trusted administrative host uploads these files, and forwards them to internal customer subnet system
Analysis
If attacker breaks into web server, cannot get order information
There is a slight window where the information of customers still on system can be obtained
Attacker can get enciphered files, public key used to encipher them
Use of public key cryptography means it is computationally infeasible for attacker to determine private key from public key
DMZ DNS Server

Supplies DNS information for some hosts to DMZ:
DMZ mail, web, log hosts Internal trusted administrative host
Not fixed for various reasons; could be
Inner firewall Outer firewall
Note: Internal server addresses not present

Inner firewall can get them, so DMZ hosts do not need them
DMZ Log Server

DMZ systems all log information
Useful in case of problems, attempted compromise
Problem: attacker will delete or alter them if successful

So log them off-line to this server
Log server saves logs to file, also to write-once media

Latter just in case log server compromised
Runs SSH server

Constrained in same way server on DMZ mail server is
Summary
Each server knows only what is needed to do its task
Compromise will restrict flow of information but not reveal info on internal network
Operating systems and software:

All unnecessary features, servers disabled Better: create custom systems
Proxies prevent direct connection to systems

For all services except SSH from internal network to DMZ, which is itself constrained by source, destination
Internal Network
Goal: guard against unauthorized access to information
read means fetching file, write means depositing file
For now, ignore email, updating of DMZ web server, internal trusted administrative host Internal network organized into 3 subnets, each corresponding to Drib group
Firewalls control access to subnets
Internal Mail Server

Can communicate with hosts on subnets Subnet may have mail server
Internal DNS need only know subnet mail servers address
Subnet may allow mail to go directly to destination host

Internal DNS needs to know addresses of all destination hosts
Either satisfies policy

WWW-close
Provides staging area for web updates All internal firewalls allow access to this
WWW-clone controls who can put and get what files and where they can be put
Synchronized with web pages on server

Done via internal trusted administrative host
Used as testbed for changes in pages

Allows corporate review before anything goes public If DMZ web server trashed or compromised, all web pages can be restored quickly
Trusted Administrative Host

Access tightly controlled
Only system administrators authorized to administer DMZ systems have access
All connections to DMZ through inner firewall must use this host
Exceptions: internal mail server, possibly DNS
All connections use SSH

DMZ SSH servers accept connections from this host only
Analysis
DMZ servers never communicate with internal servers
All communications done via inner firewall
Only client to DMZ that can come from internal network is SSH client from trusted administrative host
Authenticity established by public key authentication
Only data non-administrative folks can alter are web pages

Even there, they do not access DMZ
Analysis
Only data from DMZ is customer orders and email
Customer orders already checked for potential errors, enciphered, and transferred in such a way that it cannot be executed Email thoroughly checked before it is sent to internal mail server
November 1, 2004
Slide #1-1071
Assumptions
Software, hardware does what it is supposed to
If software compromised, or hardware does not work right, defensive mechanisms fail Reason separation of privilege is critical
If component A fails, other components provide additional defenses
Assurance is vital!
Availability
Access over Internet must be unimpeded
Context: flooding attacks, in which attackers try to overwhelm system resources
Example: SYN flood

Problem: server cannot distinguish legitimate handshake from one that is part of this attack
Only difference is whether third part of TCP handshake is sent
Flood can overwhelm communication medium

Cant do anything about this (except buy a bigger pipe)
Flood can overwhelm resources on our system

We start here
Intermediate Hosts
Use routers to divert, eliminate illegitimate traffic
Goal: only legitimate traffic reaches firewall Example: Cisco routers try to establish connection with source (TCP intercept mode)
On success, router does same with intended destination, merges the two On failure, short time-out protects router resources and target never sees flood
Intermediate Hosts
Use network monitor to track status of handshake
Example: synkill monitors traffic on network
Classifies IP addresses as not flooding (good), flooding (bad), unknown (new) Checks IP address of SYN
If good, packet ignored If bad, send RST to destination; ends handshake, releasing resources If new, look for ACK or RST from same source; if seen, change to good; if not seen, change to bad
Periodically discard stale good addresses

Intermediate Hosts
Problem: dont solve problem!
They move the locus of the problem to the intermediate system In Dribs case, Drib does not control these systems
So, consider endpoints
November 1, 2004
Slide #1-1076
Endpoint Hosts
Control how TCP state is stored
When SYN received, entry in queue of pending connections created
Remains until an ACK received or time-out In first case, entry moved to different queue In second case, entry made available for next SYN
In SYN flood, queue is always full

So, assure legitimate connections space in queue to some level of probability Two approaches: SYN cookies or adaptive time-outs
SYN Cookies
Source keeps state Example: Linux 2.4.9 kernel
Embed state in sequence number When SYN received, compute sequence number to be function of source, destination, counter, and random data
Use as reply SYN sequence number When reply ACK arrives, validate it
Must be hard to guess

Adaptive Time-Out
Change time-out time as space available for pending connections decreases Example: modified SunOS kernel
Time-out period shortened from 75 to 15 sec Formula for queueing pending connections changed:
Process allows up to b pending connections on port a number of completed connections but awaiting process p total number of pending connections c tunable parameter Whenever a + p > cb, drop current SYN message
November 1, 2004
Anticipating Attacks
Drib realizes compromise may come through unanticipated means
Plans in place to handle this
Extensive logging
DMZ log server does intrusion detection on logs
November 1, 2004
Slide #1-1080
Against Outer Firewall

Unsuccessful attacks
Logged, then ignored Security folks use these to justify budget, train new personnel
Successful attack against SMTP proxy

Proxy will start non-standard programs Anomaly detection component of IDS on log server will report unusual behavior
Security officers monitor this around the clock
In the DMZ
Very interested in attacks, successful or not Means someone who has obtained access to DMZ launched attack
Some trusted administrator shouldnt be trusted Some server on outer firewall is compromised Software on DMZ system not restrictive enough
IDS system on DMZ log server looks for misuse (known attacks) to detect this
Ignoring Failed Attacks

Sounds dangerous
Successful attacker probably tried and failed earlier
Drib: So what?
Not sufficient personnel to handle all alerts Focus is on what Drib cares most about
Successful attacks, or failed attacks where there should be none
Checking the IDS

IDS allows Drib to add attack signatures and tune parameters to control reporting of events
Experimented to find good settings Verify this every month by doing manual checks for two 1-hour periods (chosen at random) and comparing with reported events
November 1, 2004
Slide #1-1084
Key Points
Begin with policy Craft network architecture and security measures from it Assume failure will occur
Try to minimize it Defend in depth Have plan to handle failures
Chapter 24: System Security

Introduction Policy Networks Users Authentication Processes Files Retrospective
November 1, 2004
Introduction
How does administering security affect a system? Focus on two systems
DMZ web server User system in development subnet
Assumptions
DMZ system: assume any user of trusted administrative host has authenticated to that system correctly and is a trusted user Development system: standard UNIX or UNIX-like system which a set of developers can use
Policy
Web server policy discussed in Chapter 23
Focus on consequences
Development system policy components, effects Comparison
November 1, 2004
Slide #1-1088
DMZ Web Server: Consequences of Policy

1. Incoming web connections come from outer firewall 2. Users log in from trusted administrative host; web pages also downloaded through it 3. Log messages go to DMZ log host only 4. Web server may query DMZ DNS system for IP addresses 5. Other than these, no network services provided 6. Runs CGI scripts
One writes enciphered data to spool area
7. Implements services correctly, restricts access as much as possible 8. Public keys reside on web server
Constraints on DMZ Web Server

WC1 No unrequested network connections except HTTP, HTTPS from outer firewall and SSH from trusted administrative host
Replies to DNS queries from DMZ DNS okay
WC2
User access only to those with user access to trusted administrative host
Number of these users as small as possible All actions attributed to individual account, not group or group account
November 1, 2004
Slide #1-1090
Constraints on DMZ Web Server

WC3 Configured to provide minimal access to system
Transfer of enciphered file to spool area should not be under web server control
WC4 WC5
Software is high assurance

Needs extensive logging
Contains as few programs, as little software, configuration information, and other data as possible
Minimizes effects of successful attack
November 1, 2004
Development System
Development network (devnet) background
Firewall separating it from other subnets DNS server Logging server for all logs File servers User database information servers Isolated system used to build base system configuration for deployment to user systems User systems
What follows applies only to user systems

Devnet User System: Policy Components

1. 2. 3. 4. 5. 6. 7. Only authorized users can use devnet systems; can work on any workstation Sysadmins must be able to access workstations at any time Authorized users trusted not to attack systems All network communications except email confidential, integrity checked Base standard configuration cannot be changed Backups allow any system to be restored Periodic, ongoing audits of devnet systems
November 1, 2004
Consequences for Infrastructure

Firewall at boundary enforces network security policy
Changes to network policy made only at firewall Devnet systems need not be as tightly secured
No direct access between Internet, devnet systems

Developers who need to do so have separate workstations connected to commercial ISP These are physically disconnected from devnet and cannot be easily reconnected
Consequences for User Systems

DC1 DC2 Communications authenticated, enciphered, integrity checked
Consistent naming scheme across systems
Each workstation has privileged accounts for administrators

Multiple administrative accounts to limit access to particular privileged functions
DC3
Notion of audit or login identity associated with each action

So actions can be tied to individuals
November 1, 2004

DC4 DC5 DC6 Need approval to install program, and must install it in special area
Separates it from base system software
Each workstation protects base system software from being altered

Best way: keep it on read-only media
Employees files be available continuously

Even if workstation goes down Same permissions wherever employee accesses them
November 1, 2004
Slide #1-1096

DC7 Workstations store only transient files, so need not be backed up
Permanent files stores on file server, mounted remotely Software, kernel on read-only media
DC8 Logging system to hold logs needed

Security officers need access to systems, network
Procedural Mechanisms
Some restrictions cannot be enforced by technology
Moving files between ISP workstation, devnet workstation using a floppy No technological way to prevent this except by removing floppy drive
Infeasible due to nature of ISP workstations
Drib has made procedures, consequences for violating procedures, very clear
Comparison
Spring from different roles
DMZ web server not a general-use computer Devnet workstation is
DMZ web server policy: focus on web server

System provides that service (and supporting services) only; only administrative users have access as users
Devnet workstation policy: focus on more complex environment

Software creation, testing, maintenance Many different users
Networks
Both systems need appropriate network protections
Firewalls provide much of this, but separation of privilege says the systems should too
How do administrators configure these?
November 1, 2004
Slide #1-1100
DMZ Web Server

Accepts web requests only from inner firewall
May allow internal users to access web site for testing purposes in near future
Configuration file for web server software:

order a l l ow, deny a l low f r om outer_ f i rewal l a l low f r om inner_ f i rewal l deny f r om a l l evaluate allow, then deny lines anything outer firewall sends is okay anything inner firewall sends is okay dont accept anything else
Note inner firewall prevents internal hosts from accessing DMZ web server (for now)
If changed, web server configuration will stay same
DMZ Web Server: Web Server

Accepts SSH connections only from trusted administrative host Configuration file for web software:
order a l l ow, deny a l low f r om outer_ f i rewal l a l low f r om inner_ f i rewal l deny f r om a l l evaluate allow, then deny lines anything outer firewall sends is okay anything inner firewall sends is okay dont accept anything else
Note inner firewall prevents internal hosts from accessing DMZ web server (for now)
If changed, web server configuration will stay same
DMZ Web Server: SSH Server

Accepts SSH connections only from authorized users coming in from trusted administrative server
SSH provides per host and per user authentication Public keys pre-loaded on web server
Configuration file for ssh server:

a l low t r usted_admin_server deny a l l
connections from admin server okay re fuse a l lo thers
Note inner firewall prevents other internal hosts from accessing SSH server on this system
Not expected to change
Availability
Need to restart servers if they crash
Automated, to make restart quick
Script
#! /b in / sh echo $$ > /var/ servers /webdwrapper .p id whi le t r ue do /us r / loca l /b in /webd s leep 30 done
If server terminates, 30 sec later it restarts

DMZ Web Server: Clients

DNS client to get IP addresses, host names from DMZ DNS
Client ignores extraneous data If different responses to query, discard both
Logging client to send log messages to DMZ log server

Log any attempted connections to any port
Devnet Workstation
Servers:
Mail (SMTP) server
Very simple. just forwards mail to central devnet mail server
SSH server Line printer spooler Logging server
All use access control wrappers

Used to restrict connections from within devnet as well as duplicate firewall restrictions
Access Control Wrappers

TCP wrappers configured to intercept requests to active ports on workstations
Determines origin (IP address) of request If okay, allows connection transparently Log request
Access controlled by configuration file

Second program examines network requests from variety of ports If illicit activity indicated, adds commands to configuration file to block access requests from that origin
FTP, Web Services in Devnet

Special server systems
Neither is on any devnet workstation To make files, pages available place them in special areas on file server
FTP, Web servers remotely mount these areas and make them available to the server daemons
Benefits
Minimizes number of services that devnet workstations have to run Minimizes number of systems that provide these services
Checking Security
Security officers scan network ports on systems
Compare to expected list of authorized systems and open ports
Discrepencies lead to questions
Security officers attack devnet systems

Goal: see how well they withstand attacks Results used to change software, procedures to improve security
Comparison
Location
DMZ web server: all systems assumed hostile, so server replicates firewall restrictions Devnet workstation: internal systems trusted, so workstation relies on firewall to block attacks from non-devnet systems
Use
DMZ web server: serve web pages, accept commercial transactions Devnet workstation: many tasks to provide pleasant development environment for developers
Users
What accounts are needed to run systems?
User accounts (users) Administrative accounts (sysadmins)
How should these be configured and maintained?
November 1, 2004
Slide #1-1111
DMZ Web Server

At most 2 users and 1 sysadmin
First user reads (serves) web pages, writes to web transaction areas Second user moves files from web transaction area to commerce transaction spooling area Sysadmin manages system
November 1, 2004
Slide #1-1112
User Accounts
Web server account: webbie Commerce server account: ecommie CGI script (as webbie) creates file with ACL, in directory with same ACL:
( ecommie, { read, write } )
Commerce server copies file into spooling area (enciphering it appropriately), then deletes original file
Note: webbie can no longer read, write, delete file
Sysadmin Accounts
One user account per system administrator
Ties actions to individual
Never log into sysadmin account remotely

Must log into user account, then access sysadmin account
Supports tying events to individual users If audit UID not supported, may be more difficult
This is allowed from console

Useful if major problems Three people in room with console at all times
Devnet Workstation
One user account per developer Administrative accounts as needed Groups correspond to projects All identities consistent across all devnet workstations
Example: trusted host protocols, in which a user authenticated to host A can log into host B without re-authenticating
Naming Problems
Host stokes trusts host navier
User Abraham has account abby on navier Different user Abigail has account abby on stokes Now Abraham can log into Abigails account without authentication!
File server: hosts navier, stokes both use it

User abby has UID 8924 on navier User siobhan has UID 8924 on stokes File server determines access based on UID Now abby can read siobhans files, and vice versa
November 1, 2004
UINFO System
Central repository defining users, accounts
Uses NIS protocol All systems on devnet, except firewall, use it
No user accounts on workstations
Sysadmin accounts present on UINFO system

Also on each devnet workstation to allow sysadmins to fix problems with workstation accessing UINFO system (and for local restores)
Enables developers can log in to any devnet workstation

About NIS
NIS uses cleartext messages to send info
Violates requirement as no integrity checking
Not a problem in this context

Nonadministrative info: sent enciphered, integritychecked Administrative (NIS) info: vulnerable to fake answers
Idea is that a rogue system sends bogus reply before UINFO can
Not possible from inside system as are secured Not possible from outside as firewall will block message
Comparison
Differences lie in use of systems
DMZ web server: in area accessible to untrusted users
Limiting number of users limits damage successful attacker can do User info on system, so dont need to worry about network attacks on that info Few points of access
Devnet workstation: in area accessible to only trusted users

General user access system Shares user base with other systems Many points of access
Authentication
Focus here is on techniques used All systems require some form
November 1, 2004
Slide #1-1120
DMZ Web Server

SSH: cryptographic authentication for hosts
Does not use IP addresses Reject connection if authentication fails
SSH: crypto for user; password on failure

Experimenting with smart card systems, so uses PAM
Passwords: use MD-5 hash to protect passwords

Can be as long as desired Proactive password checking to ensure they are hard to guess No password aging
Devnet Workstation
Requires authentication as unauthorized people have access to physically secure area
Janitors, managers, etc.
Passwords: proactively checked

Use DES-based hash for NIS compatibility
Max password length: 8 chars
Aging in effect; time bounds (min 3d, max 90d)
SSH: like DMZ web server, except:

root access blocked Must log in as ordinary user, then change to root
Comparison
Both use strong authentication
All certificates installed by trusted sysadmins
Both allow reusable passwords

One uses MD-5, other DES-based hash One does not age passwords, other does
November 1, 2004
Slide #1-1123
Processes
What each system must run
Goal is to minimize the number of these
November 1, 2004
Slide #1-1124
DMZ Web Server

Necessary processes:
Web server
Enough privileges to read pages, execute CGI scripts
Commerce server
Enough privileges to copy files from web servers area to spool area; not enough to alter web pages
SSH server (privileged) Login server (privileged)

If a physical terminal or console
Any essential OS services (privileged)

Page daemon, etc.
Potential Problem
UNIX systems: need privileges to bind to ports under 1024
Including port 80 (for web servers) But web server is unprivileged!
Solution 1: Server starts privileged, opens port, drops privileges Solution 2: Write wrapper to open port, drop privilege, invoke web server
The wrapper passes open port to web server
File Access
Augment ACLs with something like capabilities Change process notion of root directory to limit access to files in file system Example: web server needs to access page
Without change: /usr/Web/pages/index.html After change: /pages/index.html
Cannot refer to /usr/trans as cannot name it
Example
Web server changes root directory to /usr/Web Commerce server changes root directory to /usr/trans Note xdir accessible to both processes
November 1, 2004
/ usr
Web web server
trans
commerce server
pages
xdir
1
Slide #1-1128
Interprocess Communications
Web server needs to tell commerce server a file is ready Use shared directory
Web server places file with name trnsnnnn in directory (n is digit) Commerce server periodically checks directory for files of that name, operates on them Alternative: web server signals commerce server to get file using signal mechanism
Devnet Workstation
Servers provide administrative info
Run with as few privileges as possible
Best: user nobody and group nogroup
Use master daemon to listen at ports, spawn less privileged servers to service request Servers change notion of root directory
Clients
NIS client to talk to UINFO system File server client to allow file server access
Devnet Workstation
Logging mechanism
Records OS calls, parameters, results Saves it locally, sent to central logging server
Intrusion detection done; can augment logging as needed Initially, process start, end, audit and effective UIDs recorded
Disk space
If disk utilization over 95%, program scans local systems and deletes all temp files and editor backup files not in use
Meaning have not been accessed in last 3 days
Comparison
DMZ web server: only necessary processes
New software developed, compiled elsewhere Processes run in very restrictive environment Processes write to local log, directly to log server
Devnet workstation: provides environment for developers

More processes for more tasks Process environment less restrictive to allow sharing, etc. Processes write to log server, which does all logging
Files
Protections differ due to differences in policies
Use physical limits whenever possible, as these cannot be corrupted Use access controls otherwise
November 1, 2004
Slide #1-1133
DMZ Web Server

System programs, configuration files, etc. are on CD-ROM
If attacker succeeds in breaking in, modifying in-core processes, then sysadmins simply reboot to recover Public key for internal commerce server here, too
Only web pages change

Too often to make putting them on CD-ROM Small hard drive holds pages, spool areas, temp directories, sysadmin home directory
Example
Web server: user webbie
When running, root directory is root of web page directory, /mnt/www CGI programs owned by root, located in directory (/mnt/www/cgi-bin) mounted from CD-ROM
Keys in /mnt/www/keys
Transaction files in /mnt/www/pages/trans

Readable, writable by webbie, ecommie
Commerce server: user ecommie

Periodically checks /mnt/www/pages/trans Moves files out to /home/com/transact
DMZ Web Server

Everything statically linked
No compilers, dynamic loaders, etc.
Command interpreter for sysadmin

Programs to start, stop servers Programs to edit, create, delete, view files Programs to monitor systems
No other programs
None to read mail or news, no batching, no web browsers, etc.
DMZ Web Server

Checking integrity of DMZ web server
Not done
If question:
Stop web server Transfer all remaining transaction files Reboot system from CD-ROM Reformat hard drive Reload contents of user directories, web pages from WWW-clone Restart servers
Devnet Workstation
Standard configuration for these
Provides folks with needed tools, configurations Configuration is on bootable CD-ROM
CD-ROM created on isolated workstation

Changes made to that workstation, then new CD-ROM created and distributed
Workstations also have hard drive for local writable storage

Mounted under CD-ROM Can be wiped if any question of integrity
Devnet Workstation
Logs on log server examined using intrusion detection systems
Security officers validate by analyzing 30 min worth of log entries and comparing result to reports from IDS
Scans of writable media look for files matching known patterns of intrusions
If found, reboot and wipe hard drive Then do full check of file server
November 1, 2004
Slide #1-1139
Comparison
Both use physical means to prevent system software from being compromised
Attackers cant alter CD-ROMs
Reloading systems
DMZ web server: save transaction files, regenerate system from WWW-clone
Actually, push files over to internal network system
Devnet workstation: just reboot, reformat hard drive

Files on hard drive are transient or replicated (logs)
Comparison
Devnet workstation: users trusted not to attack it
Any developer can use any devnet workstation Developers may unintentionally introduce Trojan horses, etc
Hence everything critical on read-only media
DMZ web server: fewer trusted users

Self-contained; no mounting files remotely, none of its files mounted remotely CD-ROM has minimal web server system augmented only by additional programs tailored for Dribs purpose
Summary: DMZ Web Server

Runs as few services as possible Keeps everything on unalterable media Checks source of all connections
Web: from outer firewall only SSH: from trusted administrative host only
Web, commerce servers transfer files via shared directory

They do not directly communicate
Summary: Devnet Workstation

Runs as few programs, servers as possible
Many more than DMZ web server, though
Security prominent but not dominant

Must not interfere with ability of developer to do job Security mechanisms hinder attackers, help find attackers, and enable rapid recovery from successful attack
Access from network allowed

Firewall(s) assumed to keep out unwanted users, so security mechanisms are second line of defense
Key Points
Use security policy to derive security mechanisms Apply basic principles, concepts of security
Least privilege, separation of privilege (defense in depth), economy of mechanism (as few services as possible) Identify who, what you are trusting
Chapter 25: User Security

Policy Access Files, devices Processes Electronic communications
November 1, 2004
Slide #1-1145
Policy
Assume user is on Drib development network
Policy usually highly informal and in the mind of the user
Our users policy:

U1 Only users have access to their accounts U2 No other user can read, change file without owners permission U3 Users shall protect integrity, confidentiality, availability of their files U4 Users shall be aware of all commands that they enter or that are entered on their behalf
Access
U1: users must protect access to their accounts
Consider points of entry to accounts
Passwords Login procedure Leaving system
November 1, 2004
Slide #1-1147
Passwords
Theory: writing down passwords is BAD! Reality: choosing passwords randomly makes them hard to remember
If you need passwords for many systems, assigning random passwords and not writing something down wont work
Problem: Someone can read the written password Reality: degree of danger depends on environment, how you record password
Isolated System
System used to create boot CD-ROM
In locked room; system can only be accessed from within that room
No networks, modems, etc.
Only authorized users have keys
Write password on whiteboard in room

Only people who will see it are authorized to see it
Multiple Systems
Non-infrastructure systems: have users use same password
Done via centralized user database shared by all non-infrastructure systems
Infrastructure systems: users may have multiple accounts on single system, or may not use centralized database
Write down transformations of passwords
Infrastructure Passwords
Drib devnet has 10 infrastructure systems, 2 lead admins (Anne, Paul)
Both require privileged access to all systems root, Administrator passwords chosen randomly
How to remember? Memorize an algorithm!

Anne: change case of 3rd letter, delete last char Paul: add 2 mod 10 to first digit, delete first letter
Each gets printout of transformed password

Papers for Anne and Paul

Actual password C04cEJxX 4VX9q3GA 8798Qqdt 3 W XYwgnw feOioC4f VRd0Hj9E e7Bukcba ywy j5cVw 5 iU ikLB4 af4hC2kg
November 1, 2004
Annes version C04ceJxX5 4VX9Q3 GA2 8798QqDt$ 3 W XywgnwS feo ioC4f9 VR D0Hj9Eq e7BUkcbaX ywYj5cVw* 5 iUIkLB4 m af4HC2kg+
Pauls version R C84cEJxX a2VX9q3GA 67f98Qqdt Z1 W X Ywgnw YfeOioC2f pVRd8Hj9E Xe5Bukcba rywy j3cVw 3J iU ikLB4 daf2hC2kg
Slide #1-1152
Non-Infrastructure Passwords
Users can pick
Proactive password checker vets proposed password
Recommended method: passwords based on obscure poems or sayings

Example: ttrs&vmbi from first letter of second, fourth words of each line, putting & between them:
He took his vorpal sword in hand: Long time the manxome foe he sought So rested he by the Tumtum tree, And stood awhile in thought.
Third verse of Jabberwocky, from Alice in Wonderland

Analysis
Isolated system meets U1
Only authorized users can enter room, read password, access system
Infrastructure systems meet U1

Actual passwords not written down Anne, Paul dont write down algorithms Stealing papers does not reveal passwords
Non-infrastructure systems meet U1

Proactive password checker rejects easy to guess passwords
Login Procedure
User obtains a prompt at which to enter name Then comes password prompt Attacks:
Lack of mutual authentication Reading password as it is entered Untrustworthy trusted hosts
Lack of Mutual Authentication

How does user know she is interacting with legitimate login procedure?
Attacker can have Trojan horse emulate login procedure and record name, password, then print error message and spawn real login
Simple approach: if name, password entered incorrectly, prompt for retry differed
In UNIX V6, it said Name rather than login
More Complicated
Attack program feeds name, password to legitimate login program on behalf of user, so user logged in without realizing attack program is an intermediary Approach: trusted path
Example: to log in, user hits specified sequence of keys; this traps to kernel, which then performs login procedure; key is that no application program can disable this feature, or intercept or modify data sent along this path
Reading Password As Entered

Attacker remembers it, uses it later
Sometimes called shoulder surfing Can also read chars from kernel tables, passive wiretapping, etc.
Approach: encipher all network traffic to defeat passive wiretapping

Drib: firewalls block traffic to and from Internet, internal hosts trusted not to capture network traffic Elsewhere: use SSH, SSL, TLS to provide encrypted tunnels for other protocols or to provide encrypted login facilities
Noticing Previous Logins

Many systems print time, location (terminal) of last login
If either is wrong, probably someone has unauthorized access to account; needs to be investigated
Requires user to be somewhat alert during login

Untrustworthy Trusted Hosts

Idea: if two hosts under same administrative control, each can rely on authentication from other Drib does this for backups
Backup system logs into workstation as user backup
If password required, administrator password needs to be on backup system; considered unacceptable risk Solution: all systems trust backup server
Requires accurate identification of remote host

Usually IP address Drib uses challenge-response based on cryptography
Analysis
Mutual authentication meets U1
Trusted path used when available; other times, system prints time, place of last login
Protecting passwords meets U1

Unencrypted passwords only placed on trusted network; also, system prints time, place of last login
Trusted hosts meets U1

Based on cryptography, not IP addresses; number of trusted systems minimal (backup system only)
Leaving the System

People not authorized to use systems have access to rooms where systems are
Custodians, maintenance workers, etc.
Once authenticated, users must control access to their session until it ends
What to do when one goes to bathroom?
Procedures used here

Walking Away
Procedures require user to lock monitor
Example: X window system: xlock
Only user, system administrator can unlock monitor
Note: be sure locking program does not have master override

Example: one version of lock program allowed anyone to enter Hasta la vista! to unlock monitor
November 1, 2004
Slide #1-1163
Modems
Terminates sessions when remote user hangs up
Problem: this is configurable; may have to set physical switch
If not done, next to call in connects to previous users session
Problem: older telephone systems may mishandle propagation of call termination

New connection arrives at telco switch and is forwarded before termination signal arrives at modem Same effect as above
Drib: no modems connected to development systems

Analysis
Procedures about walking away meet U1
Screen locking programs required, as is locking doors when leaving office; failure to do so involves disciplinary action If screen locking password forgotten, system administrators can remotely access system and terminate program
Procedures about modems meet U1

No modems allowed; hooking one up means getting fired (or similar nasty action)
Files and Devices

File protection allows users to refine protection afforded their data
Policy component U2 requires this
Users manipulate system through devices, so their protection affects user protection as well
Policy components U1, U4 require this
Files
Often different ways to do one thing
UNIX systems: Pete wants to allow Deb to read file design, but no-one else to do so
If Pete, Deb have their own group, make file owned by that group and group readable but not readable by others If Deb only member of a group, Pete can give group ownership of file to Deb and set permissions appropriately Pete can set permissions of containing directory to allow himself, Debs group search permission
Windows NT: same problem

Use ACL with entries for Pete, Deb only: { ( Pete, full control ), ( Deb, read ) }
File Permission on Creation

Use template to set or modify permissions when file created
Windows NT: new directory inherits parents ACL UNIX systems: identify permissions to be denied
umask contains permissions to be disabled, so can say always turn off write permission for everyone but owner when file created
Group Access
Provides set of users with same rights Advantage: use group as role
All folks working on Widget-NG product in group widgetng All files for that product group readable, writable by widgetng Membership changes require adding users to, dropping users from group
No changes to file permissions required
Group Access
Disadvantage: use group as abbreviation for set of users; changes to group may allow unauthorized access or deny authorized access
Maria wants Anne, Joan to be able to read movie System administrator puts all in group maj Later: sysadmin needs to create group with Maria, Anne, Joan, and Lorraine
Adds Lorraine to group maj Now Lorraine can read movie even though Maria didnt want her to be able to do so
File Deletion
Is the name or the object deleted? Terms
File attribute table: contains information about file File mapping table: contains information allowing OS to access disk blocks belonging to file Direct alias: directory entry naming file Indirect alias: directory entry naming special file containing name of target file
Each direct alias is alternative name for same file

Rights and Aliases

Each direct alias can have different permissions
Owner must change access modes of each alias in order to control access
Generally false
File attribute table contains access permissions for each file
So users can use any alias; rights the same
Deletion
Removes directory entry of file
If no more directory entries, data blocks and table entries released too Note: deleting directory entry does not mean file is deleted!
November 1, 2004
Slide #1-1173
Example
Anna on UNIX wants to delete file x, setuid to herself
rm x works if no-one else has a direct alias to it
Sandra has one, so file not deleted (but Annas directory entry is deleted)
File still is setuid to Anna
How to do this right:

Turn off all permissions on file Then delete it
Even if others have direct links, they are not the owners and so cant change permissions or access file
Persistence
Disk blocks of deleted file returned to pool of unused disk blocks When reassigned, new process may be able to read previous contents of disk blocks
Most systems offer a wipe or cleaning procedure that overwrites disk blocks with zeros or random bit patterns as part of file deletion Useful when files being deleted contain sensitive data
November 1, 2004
Slide #1-1175
Direct, Indirect Aliases

Some commands act differently on these
Angie executes command to add permission to file to let Lucy read it If file name direct alias, works If file name indirect alias, does it add permission to the indirect alias or the file itself?
Semantics of systems, commands on systems differ

Example: on RedHat Linux 7.1, when given indirect alias of file, chmod changes permissions of actual file, rm deletes indirect alias
Analysis
Use of ACLs, umask meet U2
Both set to deny permission toother and group by default; user can add permissions back
Group access controls meet U2

Membership in groups tightly controlled, based on least privilege
Deletion meets U2
Procedures require sensitive files be wiped when deleted
Devices
Must be protected so user can control commands sent, others cannot see interactions Writable devices Smart terminals Monitors and window systems
November 1, 2004
Slide #1-1178
Writable Devices
Restrict access to these as much as possible Example: tapes
When process begins writing, ACL of device changes to prevent other processes from writing Between mounting of media, process execution, another process can begin writing Moral: write protect all mounted media unless it is to be written to
Example: terminals
Write control sequence to erase screensend repeatedly
Smart Terminals
Has built-in mechanism for performing special functions
Most important one: block send The sequence of chars initiating block send do not appear on screen
Write Trojan horse to send command from users terminal Next slide: example in mail message sent to Craig
When Craig reads letter, his startup file becomes world writable
Trojan Horse Letter

Dear Cra ig , Please be carefu l . Someone may ask you to execute chmod 666 .pro f i le You shou ldn t do i t ! Your f r i end , Rober t <BLOCK SEN D ( -2,18) ,( 2,18)><BLOCK SEN D ( -3 ,0 ) , ( 3,18)><CLEAR>
November 1, 2004
Slide #1-1181
Why So Dangerous?
With writable terminal, someone must trick user of that terminal into executing command; both attacker and user must enter commands With smart terminal, only attacker need enter command; if user merely reads the wrong thing, the attackers compromise occurs
Monitors and Window Systems

Window manager controls what is displayed
Input from input devices Clients register with manager, can then receive input, send output through manager
How does manager determine client to get input?

Usually client in whose window input occurs
Attack: overlay transparent window on screen

Now all input goes through this window So attacker sees all input to monitor, including passwords, cryptographic keys
Access Control
Use ACLs, C-Lists, etc. Granularity varies by windowing system X window system: host name or token
Host name, called xhost method Manager determines host on which client runs Checks ACL to see if host allowed to connect
November 1, 2004
Slide #1-1184
X Windows Tokens
Called xauth method
X window manager given random number (magic cookie)
Stored in file .Xauthority in users home directory
Any client trying to connect to manager must supply this magic cookie to succeed
Local processes run by user can access this file Remote processes require special set-up by user to work
Analysis
Writable devices meet U1, U4
Devnet users have default settings denying all write access to devices except the user
Smart terminals meet U1, U4

Drib does not allow use of smart terminals except on systems where all control sequences (such as BLOCK SEND) are shown as printable chars
Window managers meet U1, U4

Drib uses either xhost or token (xhost by default) on a trusted network, so IP spoofing not an issue
Process
Manipulate objects, including files
Policy component U3 requires users to be aware of how
Copying, moving files Accidentally overwriting or erasing files Encryption, keys, passwords Start-up settings Limiting privileges Malicious logic
November 1, 2004
Copying Files
Duplicates contents Semantics determines whether attributes duplicated
If not, may need to set them to prevent compromise
Example: Mona Anne copies xyzzy on UNIX system to plugh:

cp xyzzy p l ugh If plugh doesnt exist, created with attributes of xyzzy except any setuid, setgid discarded; contents copied If plugh exists, attributes not altered; contents copied
Moving Files
Semantics determines attributes Example: Mona Anne moves xyzzy to /tmp/plugh
If both on same file system, attributes unchanged If on different file systems, semantically equivalent to:
cp xyzzy / tmp/p lugh rm xyzzy
Permissions may change
November 1, 2004
Slide #1-1189
Accidentally Overwriting Files

Protect users from themselves Example: deleting by accident
Intends to delete all files ending in .o; pattern is *.o, * matching any string Should type rm * .o Instead types rm * .o All files in directory disappear!
Use modes to protect yourself

Give i option to rm to prevent this
Encryption
Must trust system
Cryptographic keys visible in kernel buffers, swap space, and/or memory Anyone who can alter programs used to encrypt, decrypt can acquire keys and/or contents of encrypted files
Example: PGP, a public key encryption program

Protects private key with an enciphering key (passphrase), which user supplies to authenticate file If keystroke monitor installed on system, attacker gets pass-phrase, then private key, then message
Saving Passwords
Some systems allow users to put passwords for programs in files
May require file be read-protected but not use encryption
Example: UNIX ftp clients

Users can store account names, host names, passwords in .netrc Kathy did so but ftp ignored it She found file was readable by anyone, meaning her passwords stored in it were now compromised
Start-Up Settings
When programs start, often take state info, commands from environment or start-up files
Order of access affects execution
Example: UNIX command interpreter sh

When it starts, it does the following:
Read start-up file /etc/profile Read start-up file .profile in users home directory Read start-up file named in environment variable ENV
Problem: if any of these files can be altered by untrusted user, sh may execute undesirable commands or enter undesirable state on start
Limiting Privileges
Users should know which of their programs grant privileges to others
Also the implications of granting these
Example: Toni reads email for her boss, Fran

Fran knew not to share passwords, so she made a setuid-to-Fran shell that Toni could use
Bad idea; gave Toni too much power
On Tonis suggestion, Fran began to forward to Toni a copy of every letter

Toni no longer needed access to Frans account
Malicious Logic
Watch out for search paths Example: Paula wants to see Johns confidential designs
Paula creates a Trojan horse that copies design files to /tmp; calls it ls Paula places copies of this in all directories she can write to John changes to one of these directories, executes ls
Johns search path begins with current working directory
Paula gets her information

Search Paths
Search path to locate program to execute Search path to locate libraries to be dynamically loaded when program executes Search path for configuration files
November 1, 2004
Slide #1-1196
Analysis
Copying, moving files meets U3
Procedures are to warn users about potential problems
Protections against accidental overwriting and erasing meet U3

Users startup files set protective modes on login
Passwords not being stored unencrypted meets U3

In addition to policy, Drib modified programs that accept passwords from disk files to ignore those files
Analysis (cont)
Publicizing start up procedures of programs meets U3
Startup files created when account created have restrictive permissions
Publicizing dangers of setuid, giving extra privileges meets U3

When account created, no setuid/setgid programs
Default search paths meet U4

None include world writable directories; this includes symbol for current working directory
Electronic Communications
Checking for malicious content at firewall can make mistakes
Perfect detectors require solving undecidable problem Users may unintentionally send out material they should not
Automated e-mail processing Failing to check certificates Sending unexpected content
November 1, 2004
Slide #1-1199
Automated E-mail Processing

Be careful it does not automatically execute commands or programs on behalf of other users Example: NIMDA worm, embedded in email
When user opens letter, default configuration of mail passed NIMDA attachment to another program to be displayed This executes code comprising worm, thereby infecting system
November 1, 2004
Slide #1-1200
Failure to Check Certificates

If certificate invalid or expired, email signed by that certificate may be untrustworthy
Mail readers must check that certificates are valid, or enable user to determine whether to trust certificate of questionable validity
Example: Someone obtained certificates under the name of Microsoft

When discovered, issuer immediately revoked both Had anyone obtained ActiveX applets signed by those certificates, would have been trusted
Sending Unexpected Content

Arises when data sent in one format is viewed in another Example: sales director sent sales team chart showing effects of proposed reorganization
Spreadsheet also contained confidential information deleted from spreadsheet but still in the file Employees used different system to read file, seeing the spreadsheet dataand also the deleted date
Rapid saves often do not delete information, but rearrange pointers so information appears deleted
Analysis
Automated e-mail processing meets U4
All programs configured not to execute attachments, contents of letters
Certificate handling procedures meet U4

Drib enhanced all mail reading programs to validate certificates as far as possible, and display certificates it could not validate so user can decide how to proceed
Publicizing problems with risk of deleted data meets U4

Also, progams have rapid saves disabled by default
Key Points
Users have policies, although usually informal ones Aspects of system use affect security even at the user level
System access issues File and device issues Process management issues Electronic communications issues
November 1, 2004
Chapter 26: Program Security

Introduction Requirements and Policy Design Refinement and Implementation Common Security-Related Programming Problems Testing, Maintenance, and Operation Distribution
Introduction
Goal: implement program that:
Verifies users identity Determines if change of account allowed If so, places user in desired role
Similar to su(1) for UNIX and Linux systems

User supplies his/her password, not target accounts
Why?
Eliminate password sharing problem
Role accounts under Linux are user accounts If two or more people need access, both need role accounts password
Program solves this problem

Runs with root privileges User supplies his/her password to authenticate If access allowed, program spawns command interpreter with privileges of role account
Requirements
1. Access to role account based on user, location, time of request 2. Settings of role accounts environment replaces corresponding settings of users environment, but rest of users environment preserved 3. Only root can alter access control information for access to role account
More Requirements
4. Mechanism provides restricted, unrestricted access to role account
Restricted: run only specified commands Unrestricted: access command interpreter
5. Access to files, directories, objects owned by role account restricted to those authorized to use role account, users trusted to install system programs, root
Threats
Group 1: Unauthorized user (UU) accessing role accounts
1. UU accesses role account as though authorized user 2. Authorized user uses nonsecure channel to obtain access to role account, thereby revealing authentication information to UU 3. UU alters access control information to gain access to role account 4. Authorized user executes Trojan horse giving UU access to role account
Relationships
threat requirement 1 1, 5 2 3 4
November 1, 2004
notes
Restricts who can access role account, protects access control data Restricts location from where user can access role account Restricts change to trusted users Users search path restricted to own or role account; only trusted users, role account can manipulate executables
1 3 2, 4, 5
Slide #1-1211
More Threats
Group 2: Authorized user (AU) accessing role accounts
5. AU obtains access to role account, performs unauthorized commands 6. AU executes command that performs functions that user not authorized to perform 7. AU changes restrictions on users ability to obtain access to role account
Relationships
threat requirement 5 4 6 7 2, 5 3 notes
Allows user restricted access to role account, so user can run only specific commands Prevent introduction of Trojan horse root users trusted; users with access to role account trusted
November 1, 2004
Slide #1-1213
Design
Framework for hooking modules together
User interface High-level design
Controlling access to roles and commands

Interface Internals Storage of access control data
User Interface
User wants unrestricted access or to run a specific command (restricted access) Assume command line interface
Can add GUI, etc. as needed
Command
ro le ro l e_account [com m and ]
where
role_account name of role account command command to be run (optional)
High-Level Design
1. Obtain role account, command, user, location, time of day
If command omitted, assume command interpreter (unrestricted access)
2. Check user allowed to access role account

a) at specified location; b) at specified time; and c) for specified command (or without restriction)
If user not, log attempt and quit

High-Level Design (cont)

3. Obtain user, group information for role account; change privileges of process to role account 4. If user requested specific command, overlay process with command interpreter that spawns named command 5. If user requested unrestricted access, overlay process with command interpreter allowing interactive use
Ambiguity in Requirements
Requirements 1, 4 do not say whether command selection restricted by time, location
This design assumes it is
Backups may need to be run at 1AM and only 1AM Alternate: assume restricted only by user, role; equally reasonable
Update requirement 4 to be: Mechanism provides restricted, unrestricted access to role account
Restricted: run only specified commands Unrestricted: access command interpreter
Level of access (restricted, unrestricted) depends on user, role, time, location

Access to Roles, Commands

Module determines whether access to be allowed
If it cant get user, role, location, and/or time, error; return failure
Interface: controls how info passed between module, caller Internal structure: how does module handle errors, access control data structures
Interface to Module
Minimize amount of information being passed through interface
Follow standard ideas of information hiding Module can get user, time of day, location from system So, need pass only command (if any), role account name
boo lean accessok(ro le rname, com mand cmd)
rname: name of role cmd: command (empty if unrestricted access desired) returns true if access granted, false if not (or error)
Internals of Module
Part 1: gather data to determine if access allowed Part 2: retrieve access control information from storage Part 3: compare two, determine if access allowed
November 1, 2004
Slide #1-1221
Part 1
Required:
user ID: who is trying to access role account time of day: when is access being attempted
From system call to operating system
entry point: terminal or network connection remote host: name of host from which user accessing local system (empty if on local system)
These make up location
Part 2
Obtain handle for access control file
May be called a descriptor
Contents of file is sequence of records:

ro le account user names l oca t ions f rom wh ich the ro le account can be accessed t imes when the ro le account can be accessed com mand and arguments
Can list multiple commands, arguments in 1 record

If no commands listed, unrestricted access
Part 3
Iterate through access control file
If no more records
Release handle Return failure
Check role
If not a match, skip record (go back to top)
Check user name, location, time, command

If any does not match, skip record (go back to top)
Release handle Return success

Storing Access Control Data

Sequence of records; what should contents of fields be?
Location: *any*, *local*, host, domain; operators not, or (,)
* loca l *, con t ro l . f i x i t . com , .wat chu .edu
User: *any*, user name; operators not, or (,)

peter ,pau l,mary ,j oan ,jan is
Time: *any*, time range

Time Representation
Use ranges expressed (reasonably) normally
Mon-Thu 9A M-5P M Any time between 9AM and 5PM on Mon, Tue, Wed, or Thu Mon 9A M-Thu 5P M Any time between 9AM Monday and 5PM Thursday Apr 15 8AM-Sep 15 6P M Any time from 8AM on April 15 to 6PM on September 15, on any year
Commands
Command plus arguments shown
/b in / i nsta l l* Execute /bin/install with any arguments /b in /cp log /var/inst/log Copy file log to /var/inst/log /us r /bi n / id Run program id with no arguments
User need not supply path names, but commands used must be the ones with those path names
Refinement and Implementation

First-level refinement Second-level refinement Functions
Obtaining location Obtaining access control record Error handling in reading, matching routines
November 1, 2004
Slide #1-1228
First-Level Refinement
Use pseudocode:
boo lean accessok( r o le rname, com mand cmd) ; s ta t fa l se user obta in user ID t imeday obta in t ime o f day ent ry obta in en t r y po in t( termina ll i n e, remote hos t ) open access cont r o lf i l e repeat rec ge t nex t record f rom f i l e; EOF i fnone i frec EOF then s ta t match( rec , rname, cmd, user ,t imeday, ent ry ) unt i lrec = EOF or sta t =t rue c lose access cont r o lf i l e re tu rn s tat
November 1, 2004
Slide #1-1229
Check Sketch
Interface right Stat (holds status of access control check) false until match made, then true Get user, time of day, location (entry) Iterates through access control records
Get next record If there was one, sets stat to result of match Drops out when stat true or no more records
Close file, releasing handle Return stat

November 1, 2004
Slide #1-1230
Second-Level Refinement
Map pseudocode to particular language, system
Well use C, Linux (UNIX-like system) Role accounts same as user accounts
Interface decisions
User, role ID representation Commands and arguments Result
Users and Roles

May be name (string) or uid_t (integer)
In access control file, either representation okay
If bogus name, cant be mapped to uid_t Kernel works with uid_t

So access control part needs to do conversion to uid_t at some point
Decision: represent all user, role IDs as uid_t Note: no design decision relied upon representation of user, role accounts, so no need to revisit any
Commands, Arguments, Result

Command is program name (string) Argument is sequence of words (array of string pointers) Result is boolean (integer)
November 1, 2004
Slide #1-1233
Resulting Interface
i n t accessok(u i d_trname, char *cmd[] ) ;
November 1, 2004
Slide #1-1234
Second-Level Refinement
Obtaining user ID Obtaining time of day Obtaining location Opening access control file Processing records Cleaning up
November 1, 2004
Obtaining User ID
Which identity?
Effective ID: identifies privileges of process
Must be 0 (root), so not this one
Real ID: identifies user running process user i d = getu i d( ) ;
November 1, 2004
Slide #1-1236
Obtain Time of Day

Internal representation is seconds since epoch
On Linux, epoch is Jan 1, 1970 00:00:00 t imeday = t i me(N ULL) ;
November 1, 2004
Slide #1-1237
Obtaining Location
System dependent
So we defer, encapsulating it in a function to be written later ent r y = get locat ion( ) ;
November 1, 2004
Slide #1-1238
Opening Access Control File

Note error checking and logging
i f( ( fp= fopen(ac f i l e, r ) )== NULL) { logerro r (e r r no, ac f i l e ) ; re tu r n(s ta t ) ; }
November 1, 2004
Slide #1-1239
Processing Records
Internal record format not yet decided
Note use of functions to delay deciding this
do { ac rec = ge t nextacrec( fp ) ; i f(acrec != NULL) s t at = match( r ec, rname, cmd, user , t imeday, en t ry ) ; } un t i l( acrec == NULL | |s t at == 1) ;
November 1, 2004
Slide #1-1240
Cleaning Up
Release handle by closing file
(vo id )f c lose( fp ) ; re tu r n(s ta t ) ;
November 1, 2004
Slide #1-1241
Getting Location
On login, Linux writes user name, terminal name, time, and name of remote host (if any) in file utmp Every process may have associated terminal To get location information:
Obtain associated process terminal name Open utmp file Find record for that terminal Get associated remote host from that record
November 1, 2004
Security Problems
If any untrusted process can alter utmp file, contents cannot be trusted
Several security holes came from this
Process may have no associated terminal Design decision: if either is true, return meaningless location
Unless location in access control file is any wildcard, fails
getl ocat i on() Outline

hostname get locat ion( ) myterm name o fte rmina l assoc ia ted wi th p rocess obta in u t mp f i le access cont ro ll i s t i f any user o ther than root can a l t er i tthen re tu rn * nowhere* open u t mp f i le repeat te rm get nex t record f rom u tmp f i le ; EOF i f none i fte rm EOF and myterm = te r m then s ta t t r ue e lse s ta t fa lse unt i lte r m = EOF or s ta t =t rue i f hos tf i e ld in u t mp record = empty then host l oca lhost e lse host hos tf ie ld o f utmp record c lose u t mp f i le re tu rn host
Access Control Record

Consider match routine
User name is uid_t (integer) internally
Easiest: require user name to be uid_t in file Problems: (1) human-unfriendly; (2) unless binary data recorded, still need to convert Decision: in file, user names are strings (names or string of digits representing integer)
Location, set of commands strings internally

Decision: in file, represent them as strings
Time Representation
Here, time is an interval
May 30 means any time on May 30, or May 30 12AM-May 31 12AM
Current time is integer internally

Easiest: require time interval to be two integers Problems: (1) human-unfriendly; (2) unless binary data recorded, still need to convert Decision: in file, time interval represented as string
Record Format
Here, commands is repeated once per command, and numcommands is number of commands fields
record ro le rname s t r ing user l i s t s t r ing l ocat ion s t r ing t i meofday s t r ing com mands[ ] s t r ing com mands[ ] i n teger numcom mands end record ;
May be able to compute numcommands from record November 1, 2004 Introduction to Computer Security Slide #1-1247
2004 Matt Bishop
Error Handling
Suppose syntax error or garbled record Error cannot be ignored
Log it so system administrator can see it
Include access control file name, line or record number
Notify user, or tell user why there is an error, different question

Can just say access denied If error message, need to give access control file name, line number
Suggests error, log routines part of accessok module

Implementation
Concern: many common security-related programming problems
Present management and programming rules Use framework for describing problems
NRL: our interest is technical modeling, not reason for or time of introduction Aslam: want to look at multiple components of vulnerabilities Use PA or RISOS; we choose PA
Improper Choice of Initial Protection Domain

Arise from incorrect setting of permissions or privileges
Process privileges Access control file permissions Memory protection Trust in system
November 1, 2004
Slide #1-1250
Process Privileges
Least privilege: no process has more privileges than needed, but each process has the privileges it needs Implementation Rule 1:
Structure the process so that all sections requiring extra privileges are modules. The modules should be as small as possible and should perform only those tasks that require those privileges.
Basis
Reference monitor
Verifiable: here, modules are small and simple Complete: here, access to privileged resource only possible through privileges, which require program to call module Tamperproof: separate modules with well-defined interfaces minimizes chances of other parts of program corrupting those modules
Note: this program, and these modules, are not reference monitors!
Were approximating reference monitors
More Process Privileges

Insufficient privilege: denial of service Excessive privilege: attacker could exploit vulnerabilities in program Management Rule 1:
Check that the process privileges are set properly.
November 1, 2004
Slide #1-1253
Can we have privileged modules in our environment?
No; this is a function of the OS Cannot acquire privileges after start, unless process started with those privileges
Which role account?

Non-root: requires separate program for each role account Root: one program can handle all role accounts
Program and Privilege

Program starts with root privileges Access control module called
Needs these privileges to read access control file
Privileges released
But they can be reacquired
Privileges reacquired for switch to role account

Because root can switch to any user
Key points: privileges acquired only when needed, and relinquished once immediate task is complete
Access Control File Permissions

Integrity of process relies upon integrity of access control file Management Rule 2:
The program that is executed to create the process, and all associated control files, must be protected from unauthorized use and modification. Any such modification must be detected.
Program and File

Program checks integrity of access control file whenever it runs Check dependencies, too
If access control file depends on other external information (like environment variables, included files, etc.), check them Document these so maintainers will know what they are
Permissions
Set these so only root can alter, move program, access control file Implementation Rule 2:
Ensure that any assumptions in the program are validated. If this is not possible, document them for the installers and maintainers, so they know the assumptions that attackers will try to invalidate.
UNIX Implementation
Checking permissions: 3 steps
Check root owns file Check no group write permission, or that root is single member of the group owner of file
Check list of members of that group first Check password file next, to ensure no other users have primary GID the same as the group; these users need not be listed in group file to be group members
Check no world read, write permission

Memory Protection
Shared memory: if two processes have access, one can change data other relies upon, or read data other considers secret Implementation Rule 3
Ensure that the program does not share objects in memory with any other program, and that other programs cannot access the memory of a privileged process.
Memory Management
Dont let data be executed, or constants change
Declare constants in program as const Turn off execute permission for data pages/segments Do not use dynamic loading
Management Rule 3:
Configure memory to enforce the principle of least privilege. If a section of memory is not to contain executable instructions, turn execute permission off for that section of memory. If the contents of a section of memory are not to be altered, make that section read-only.
Trust
What does program trust?
System authentication mechanisms to authenticate users UINFO to map users, roles into UIDs Inability of unprivileged users to alter system clock
Management Rule 4:
Identify all system components on which the program depends. Check for errors whenever possible, and identify those components for which error checking will not work.
November 1, 2004
Slide #1-1262
Improper Isolation of Implementation Detail

Look for errors, failures of mapping from abstraction to implementation
Usually come out in error messages
Implementation Rule 4:
The error status of every function must be checked. Do not try to recover unless the cause of the error, and its effects, do not affect any security considerations. The program should restore the state of the system to the state before the process began, and then terminate.
Resource Exhaustion, User Identifiers

Role, user are abstractions
The system works with UIDs
How is mapping done?

Via user information database
What happens if mapping cant be made?

In one mail server, returned a default userso by arranging that the mapping failed, anyone could have mail appended to any file to which default user could write Better: have program fail
Validating Access Control Entries

Access control file data implements constraints on access
Therefore, its a mapping of abstraction to implementation
Develop second program using same modules as first

Prints information in easy-to-read format Must be used after each change to file, to verify change does what was desired Periodic checks too
Restricting Protection Domain

Use overlays rather than spawning child
Overlays replace original protection domain with that of overlaid program Programmers close all open files, reset signal handlers, changing privileges to that of role Potential problem: saved UID, GID
When privileges dropped in usual way, can regain them because original UID is saved; this is how privileges restored Use setuid system call to block this; it changes saved UID too
November 1, 2004
Slide #1-1266
Improper Change
Data that changes unexpectedly or erroneously Memory File contents File/object bindings
November 1, 2004
Slide #1-1267
Memory
Synchronize interactions with other processes Implementation Rule 5:
If a process interacts with other processes, the interactions should be synchronized. In particular, all possible sequences of interactions must be known and, for all such interactions, the process must enforce the required security policy.
More Memory
Asynchronous exception handlers: may alter variables, state
Much like concurrent process
Asynchronous exception handlers should not alter any variables except those that are local to the exception handling module. An exception handler should block all other exceptions when begun, and should not release the block until the handler completes execution, unless the handler has been designed to handle exceptions within itself (or calls an uninvoked exception handler).
November 1, 2004
Slide #1-1269
Buffer Overflows
Overflow not the problem Changes to variables, state caused by overflow is the problem
Example: fingerd example: overflow changes return address to return into stack
Fix at compiler level: put random number between buffer, return address; check before return address used
Example: login program that stored unhashed, hashed password in adjacent arrays
Enter any 8-char password, hit space 72 times, enter hash of that password, and system authenticates you!
Problem
Trusted data can be affected by untrusted data
Trusted data: return address, hash loaded from password file Untrusted data: anything user reads
Whenever possible, data that the process trusts and data that it receives from untrusted sources (such as input) should be kept in separate areas of memory. If data from a trusted source is overwritten with data from an untrusted source, a memory error will occur.
Our Program
No interaction except through exception handling
Implementation Rule 5 does not apply
Exception handling: disable further exception handling, log exception, terminate program
Meets Implementation Rule 6
Do not reuse variables used for data input; ensure no buffers overlap; check all array, pointer references; any out-of-bounds reference invokes exception handler
Meets Implementation Rule 7
File Contents
If access control file changes, either:
File permissions set wrong (Management Rule 2) Multiple processes sharing file (Implementation Rule 5)
Dynamic loading: routines not part of executable, but loaded from libraries when program needs them
Note: these may not be the original routines
Do not use components that may change between the time the program is created and the time it is run. November 1, 2004 Introduction to Computer Security Slide #1-1273
2004 Matt Bishop
Race Conditions
Time-of-check-to-time-of-use (TOCTTOU) problem
Issue: dont want file to change after validation but before access UNIX file locking advisory, so cant depend on it
How we deal with this:

Open file, obtaining file descriptor Obtain status information using file descriptor Validate file access
UNIX semantics assure this is same as for open file object; no changing possible
Improper Naming
Ambiguity in identifying object Names interpreted in context
Unique objects cannot share names within available context Interchangeable objects can, provided they are truly interchangeable
Management Rule 5:
Unique objects require unique names. Interchangeable objects may share a name.
Contexts
Program must control context of interpretation of name
Otherwise, the name may not refer to the expected object
Example: loadmodule problem

Dynamically searched for, loaded library modules Executed program ld.so with superuser privileges to do this Default context: use /bin/ld.so (system one) Could change context to use /usr/anyone/ld.so (one with a Trojan horse)
Example
Context includes:
Character set composing name Process, file hierarchies Network domains Customizations such as search path Anything else affecting interpretation of name
The process must ensure that the context in which an object is named identifies the correct object.
Sanitize of Not?
Replace context with known, safe one on start-up
Program controls interpretation of names now
File names (access control file, command interpreter program)

Use absolute path names; do not create any environment variables affecting interpretation
User, role names

Assume system properly maintained, so no problems
Host names
No domain part means local domain
Improper Deallocation, Deletion

Sensitive information can be exposed if object containing it is reallocated
Erase data, then deallocate

When the process finishes using a sensitive object (one that contains confidential information or one that should not be altered), the object should be erased, then deallocated or deleted. Any resources not needed should also be released.
Our Program
Cleartext password for user
Once hashed, overwritten with random bytes
Access control information

Close file descriptor before command interpreter overlaid
Because file descriptors can be inherited, and data from corresponding files read
Log file
Close log file before command interpreter overlaid
Same reasoning, but for writing
Improper Validation
Something not checked for consistency or correctness
Bounds checking Type checking Error checking Checking for valid, not invalid, data Checking input Designing for validation
November 1, 2004
Bounds Checking
Indices: off-by-one, signed vs. unsigned Pointers: no good way to check bounds automatically Implementation Rule 11:
Ensure that all array references access existing elements of the array. If a function that manipulates arrays cannot ensure that only valid elements are referenced, do not use that function. Find one that does, write a new version, or create a wrapper.
November 1, 2004
Slide #1-1282
Our Program
Use loops that check bounds in our code Library functions: understand how they work
Example: copying strings
In C, string is sequence of chars followed by NUL byte (byte containing 0) strcpy never checks bounds; too dangerous strncpy checks bounds against parameter; danger is not appending terminal NUL byte
Example: input user string into buffer

gets reads, loads until newline encountered fgets reads, loads until newline encountered or a specific number of characters are read
Type Checking
Ensure arguments, inputs, and such are of the right type
Interpreting floating point as integer, or shorts as longs

Check the types of functions and parameters.
Compilers
Most compilers can do this
Declare functions before use; specify types of arguments, result so compiler can check If compiler cant do this, usually other programs can use them!
Management Rule 6:
When compiling programs, ensure that the compiler flags report inconsistencies in types. Investigate all such warnings and either fix the problem or document the warning and why it is spurious.
Error Checking
Always check return values of functions for errors
If function fails, and program accepts result as legitimate, program may act erroneously

Check all function and procedure executions for errors.
Our Program
Every function call, library call, system call has return value checked unless return value doesnt matter
In some cases, return value of close doesnt matter, as program exits and file is closed Here, only true on denial of access or error
On success, overlay another program, and files must be closed before that overlay occurs
Check for Valid Data

Know what data is valid, and check for it
Do not check for invalid data unless you are certain all other data will be valid for as long as the program is used!

Check that a variables values are valid.
November 1, 2004
Slide #1-1288
Example
Program executed commands in very restrictive environment
Only programs from list could be executed
Scanned commands looking for metacharacters before passing them to shell for execution
Old shell: ` ordinary character New shell: `x` means run program x, and replace `x` with the output of that program
Result: you could execute any command

Our Program
Checks that command being executed matches authorized command
Rejects anything else
Problem: can allow all users except a specific set to access a role (keyword not)
Added because on one key system, only system administrators and 1 or 2 trainees Used on that system, but recommended against on all other systems
Handling Trade-Off
Decision that weakened security made to improve useability
Document it and say why
Management Rule 7:
If a trade-off between security and other factors results in a mechanism or procedure that can weaken security, document the reasons for the decision, the possible effects, and the situations in which the compromise method should be used. This informs others of the trade-off and the attendant risks.
Checking Input
Check all data from untrusted sources
Users are untrusted sources

Check all user input for both form and content. In particular, check integers for values that are too big or too small, and check character data for length and valid characters.
Example
Setting variables while printing
i contains 2, j contains 21
pr in t f ( % d %d %n % d\n% n,i ,j , &m, i , &n) ;
stores 4 in m and 7 in n
Format string attack

User string input stored in str, then
pr in t f (st r )
User enters log%n, overwriting some memory location with 3

If attacker can figure out where that location is, attacker can change the value in that memory location to any desired value
Designing for Validation

Some validations impossible due to structure of language or other factors
Example: in C, test for NULL pointer, but not for valid pointer (unless valid means NULL)
Design, implement data structures in such a way that they can be validated Implementation Rule 16:
Create data structures and functions in such a way that they can be validated.
Access Control Entries

Syntax of file designed to allow for easy error detection:
ro le name users com ma-separa t ed l i s tof users l oca t ion comma-separa ted l i s to flocat ions t ime com ma-separa ted l i s to ft imes com mand command and arguments com mand command and arguments endro le
Performs checks on data as appropriate

Example: each listed time is a valid time, etc.
Improper Indivisibility
Operations that should be indivisible are divisible
TOCTTOU race conditions, for example Exceptions can break single statements/function calls, etc. into 2 parts as well

If two operations must be performed sequentially without an intervening operation, use a mechanism to ensure that the two cannot be divided.
November 1, 2004
Slide #1-1296
Our Program
Validation, then open, of access control file
Method 1: do access check on file name, then open it
Problem: if attacker can write to directory in full path name of file, attacker can switch files after validation but before opening
Method 2 (program uses this): open file, then before reading from it do access check on file descriptor
As check is done on open file, and file descriptor cannot be switched to another file unless closed, this provides protection
Method 3 (not implemented): do it all in the kernel as part of the open system call!
Improper Sequencing
Operations performed in incorrect order Implementation Rule 18:
Describe the legal sequences of operations on a resource or object. Check that all possible sequences of the program(s) involved match one (or more) legal sequences.
November 1, 2004
Slide #1-1298
Our Program
Sequence of operations follow proper order:
User authenticated Program checks access If allowed:
New, safe environment set up Command executed in it
When dropping privileges, note ordinary user cannot change groups, but root can
Change group to that of role account Change user to that of role account
Improper Choice of Operand or Operation

Erroneous selection of operation or operand Example: su used to access root account
Requires user to know root password If no password file, cannot validate entered password One program assumed no password file if it couldnt open it, and gave user root access to fix problem
Attacker: open all file descriptors possible, spawn suas open file descriptors inherited, su couldnt open any filesnot even password file Improper operation: should have checked to see if no password file or no available file descriptors
Assurance
Use assurance techniques
Document purpose, use of each function Check algorithm, call
Management Rule 8:
Use software engineering and assurance techniques (such as documentation, design reviews, and code reviews) to ensure that operations and operands are appropriate.
Our Program
Granting Access
Only when entry matches all characteristics of current session
When characteristics match, verify access control module returns true Check when module returns true, program grants access and when module returns false, denies access
Consider UID (type uid_t, or unsigned integer)

Check that it can be considered as integer
If comparing signed and unsigned, then signed converted to unsigned; check there are no comparisons with negative numbersr
Our Program (cont)

Consider location
Check that match routine correctly determines whether location passed in matches pattern in location field of access control entries, and module acts appropriately
Consider time (type time_t)

Check module interprets time as range Example: 9AM means 09:00:0009:59:59, not 09:00:00
If interpreted as exactly 9:00:00, almost impossible for user to hit exact time, effectively disabling the entry; violates Requirement 4
Our Program (cont)

Signal handlers
Signal indicates: error in program; or request from user to terminate Signal should terminate program If program tries to recover, and continues to run, and grants access to role account, either it continued in face of error, or it overrode users attempt to terminate program
Either way, choice of improper operation
Summary
Approach differs from using checklist of common vulnerabilities Approach is design approach
Apply it at each level of refinement Emphasizes documentation, analysis, understanding or program, interfaces, execution environment Documentation will help other analysts, or folks moving program to new system with different environment
Testing
Informal validation of design, operation of program
Goal: show program meets stated requirements If requirements drive design, implementation then testing likely to uncover minor problems If requirements ill posed, or change during development, testing may uncover major problems
In this case, do not add features to meet requirements! Redesign and reimplement
November 1, 2004
Slide #1-1306
Process
Construct environment matching production environment
If range of environments, need to test in all
Usually considerable overlap, so not so bad
If repeated failures, check developer assumptions

May have embedded information about development environmentone different than testing environment!
Steps
Begin with requirements
Appropriate? Does it solve the problem?
Proceed to design
Decomposition into modules allows testing of each module, with stubs to take place of uncompleted modules
Then to implementation
Test each module Test interfaces (composition of modules)
Philosophy
Execute all possible paths of control
Compare results with expected results
In practise, infeasible
Analyze paths, order them in some way
Order depends on requirements
Generate test data for each one, check each
Security testing: also test least commonly used paths

Usually not as well checked, so miss vulnerabilities
First check modules, then check composition

Testing Module
Goal: ensure module acts correctly
If it calls functions, correctly regardless of what functions return
Step 1: define correct behavior

Done during refinement, when module specified
Step 2: list interfaces to module

Use this to execute tests
Types of Tests
Normal data tests
Unexceptional data Exercise as many paths of control as possible
Boundary data tests

Test limits to interfaces Example: if string is at most 256 chars, try 255, then 256, then 257 chars Example: in our program, try UID of 1 in parameter list
Is it rejected or remapped to 2311 or 2161?
Types of Tests (cont)

Exception tests
How module handle interrupts, traps Example: send program signal to cause core dump, see if passwords visible in that file
Random data tests

Give module data generated randomly Module should fail but restore system to safe state Example: in one study of UNIX utilities, 30% crashed when given random inputs
Testing Composed Modules

Consider module that calls other modules Error handling tests
Assume called modules violate specifications See if this module violates specification
Example: logging via mail program

Program logs connecting host by mail
mai l s hos t name netadmin
Gets host name by mapping IP address using DNS DNS has fake record: hi nobody; rm -r f* ;t rue When mail command executed, deletes files
Testing Program
Testers assemble program, documentation New tester follows instructions to install, configure program and tries it
This tester should not be associated with other testers, so can provide independent assessment of documentation, correctness of instructions
Problems may be with documentation, installation program or scripts, or program itself

Distribution
Place program, documentation in repository where only authorized people can alter it and from where it can be sent to recipients Several factors afftct how this is done
November 1, 2004
Slide #1-1315
Factors
Who can use this program?
Licensed to organization: tie each copy to the organization so it cannot be redistributed
How can availability be ensured?

Physical means: distribute via CD-ROM, for example
Mail, messenger services control availability
Electronic means: via ftp, web, etc.

Ensure site is available
Factors (cont)
How to protect integrity of master copy?
Attacker changing distribution copy can attack everyone who gets it Example: tcp_wrappers altered at repository to incluse backdoor; 59 hosts compromised when they downloaded and installed it Damages credibility of vendor Customers may disbelieve vendors when warned
Key Points
Security in programming best done by mimicing high assurance techniques Begin with requirements analysis and validation Map requirements to design Map design to implementation
Watch out for common vulnerabilities
Test thoroughly Distribute carefully


Information Security Text Book

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Information Security Text Book

Загружено:

Авторское право:

Доступные форматы

CIS 739 COMPUTER SECURITY

Introduction to Computer Security 2004 Matt Bishop

Policies and Mechanisms

Mechanisms enforce policies Composition of policies

Introduction to Computer Security 2004 Matt Bishop

Trust and Assumptions

set of reachable states

set of secure states

Laws and Customs

Introduction to Computer Security 2004 Matt Bishop

Trust and knowing assumptions Importance of assurance The human factor

Chapter 2: Access Control Matrix

Introduction to Computer Security 2004 Matt Bishop

Access control matrix

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Commands often called transformation procedures

destroy subject s; destroy object o

enter r into A[s, o]

delete r from A[s, o]

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Chapter 3: Foundational Results

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

B C D s1 head Current state is k s2 s3 s4

own Ck own D end

Introduction to Computer Security 2004 Matt Bishop

own X own D k1 end

Introduction to Computer Security 2004 Matt Bishop

own X own Y own b k2 end

Introduction to Computer Security 2004 Matt Bishop

Conclusion: safety question undecidable

Introduction to Computer Security 2004 Matt Bishop

Chapter 4: Security Policies

The nature of mechanisms

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Introduction to Computer Security 2004 Matt Bishop

Types of Security Policies

Commercial security policy

Integrity and Transactions

Perform series of actions (transaction)

Trust in Formal Verification

Trust in Formal Methods

4. Hardware executes S as intended

Types of Access Control

Mandatory Access Control (MAC)

Originator Controlled Access Control (ORCON)

Introduction to Computer Security 2004 Matt Bishop

If not explicit in computer security policy, certainly implicit

Introduction to Computer Security 2004 Matt Bishop

Example English Policy

Authorized Use Policy Electronic Mail Policy

Authorized Use Policy

Procedural enforcement mechanisms

Written informally, aimed at user community

Introduction to Computer Security 2004 Matt Bishop