R

R

R

Program Security

R

R

RProgramming Issues of Security

• Types and effects of flaws and malicious code

• Techniques to help control program threats

R

R

RMalicious Code

• Definition: unexpected or undesired effects in programs or parts caused by an agent intent on damage. [Pfleeger97]

• Two main categories:– Programs that compromise or change data– Programs that affect computer service

R

R

RTypes of Malicious Code

Code Type Characteristics

Virus Attaches itself to program and propagates copies to other programs

Trojan horse Contains unexpected, additional functionality

Logic bomb Triggers action when condition occurs

Time bomb Triggers action when specified time occurs

Trapdoor Allows unauthorized access functionality

Worm Propagates copies of itself through a network

Rabbit Replicates itself without limit to exhaust resource

[Pfleeger97]

R

R

RHomes for Viruses

• Objective:– Hard to detect– Hard to destroy or

deactivate– Spreads infection

widely– Can reinfect– Easy to create– Machine (and OS)

independent

• Candidate Homes:• Boot Sector• Memory:

• Interprets keys• Error handlers

• Application Program

• Macro feature• Libraries:

• Used by many programs

Cause and Effects [Pfleeger97]VIRUS EFFECT HOW IT IS CAUSED

Attach to exec. Program •Modify file directory•Write to executable program

Attach to data or control file •Modify directory•Rewrite data•Append to data•Append data to self

Remain in memory •Intercept interrupt by modifying interrupt handler address table•Load self in nontransient memory area

Infect disks •Intercept interrupt•Intercept OS system call (e.g, format disk)•Modify system file•Modify ordinary executable program

Conceal self •Intercept system calls that would reveal identity and falsify result•Classify self as “hidden” file

Spread infection •Infect boot ssector•Infect system program•Infect ordinary program•Infect data ordinary program reads to gain control

Prevent deactivation •Activate before deactivating program and block deactivation•Store copy to reinfect after deactivation

R

R

RHow to Prevent Viruses

• Use only commercial SW from reliable, well-established vendors

• All new SW should be tested on isolated computer.– Look for unexpected behavior– Scan for viruses

• Make a bootable diskette (store safely)– Modify startup files on diskette to use system files from diskette

(drivers, memory mgmt sw, etc.)

• Create and retain backup copies of executable system files– Enable clean install after virus infection

• Use virus scanners regularly: – Multiple scanners better than just one– Update regularly

R

R

RControls against Threats

• Peer reviews• Good SE development practices:

– Modularity: decompose task into subtasks– Encapsulation: minimize coupling between modules– Information Hiding: modules have limited effects on other modules

• Independent Testing• Configuration Management

– Changes are monitored carefully (protect from unintentional threats)– Once reviewed program is accepted, programmers cannot covertly make

changes, such as trapdoors (protect from malicious threats)

• Proofs of Program Correctness• Process Improvement:

– CMM– Standards (e.g., 2167A, ISO9000)

R

R

R

Trusted Operating Systems

R

R

RWe will cover

• Memory Protection

• File protection

• General object access control

• User authentication

R

R

RProtected Objects

• Multiprogramming required protection for:– Memory– Sharable I/O devices (e.g. disks)– Serially reusable devices (e.g., printers,

tape drives)– Sharable programs and subprocedures– Sharable data

R

R

RSecurity Methods

• Physical separation:– Processes use different physical objects – (E.g., separate printers)

• Temporal separation:– Processes with different security requirements execute at

different TIMES

• Logical separation:– Users operate within their own “domain”– OS constrains program access to permitted parts

• Cryptographic Separation:– Processes conceal data and computations from outsiders

R

R

RMemory Protection

• Fences:– Protected sections of memory– Designed for single-user systems– Facilitates relocation (logical vs physical)

• Base/bounds registers– Base register: variable fence register

• Lower bound for for addresses

– Bounds register: upper address limit– Supports multiple users:

• each user has values for base and bounds regs

– Context Switch: OS updates base/bounds regs– Can have 2 pairs of base/bounds:

• One for executable programs• One for data

R

R

RMemory Protection (cont’d)

• Tagged architecture– Some number of extra bits used to indicate access (read-only,

execute-only, write)– Adjacent locns can have diff. Accesses– Separate different classes of data (numeric, char,

address/pointer)– Only used for few systems

• Burroughs B6500-7500 uses 3 tag bits to separate data words, descriptors (ptrs), and control words (stack ptrs and addressing control words)

• IBM System/38: tag bits for integrity and access

– Challenge: is compatability of code• Legacy OS systems• Cheaper memory will make this more feasible

Memory Protection: Segmentation

• Divide program into logical pieces – (data, code for 1 procedure)

• Soln for unbounded number of base/bounds reg. with diff. access rights

• Each segment has unique name:– Code or data item has address: <

name, offset>• For efficiency:

– Each process has seg. addr table

• Benefits:– Each address reference checked for

protection– Different classes of data have different

types of protection

• Weaknesses:– Efficiency of encoding segment names– Fragmentation of memory

MAIN

SEG_AFETCH <DATA_SEG,20>

SUB

DATA_SEG

MAIN c

SEG_A e

SUB a

DATA_SEG f

0

a

b

c

de

fg

h

i

+

Logical Program

Segment Translation Table

R

R

RMemory Protection: Paging

• Page: Program divided into equal-sized pieces– Page size: power of 2 between 512 and 4096 bytes

• Page Frames: Memory divided into same-sized units• Benefits:

– No fragmentation problem, all pages are same size– No problem of addressing beyond end of page

• Weaknesses:– Programmer has to keep track of segments– No logical unity to a page– Lose ability to have fine-grained protection mechanisms

• Hybrid approach: combines advantages of both– Segments are decomposed into pages– IBM 37– Multics OS

R

R

RFile Protection

• Based on 3-4-level format (user-group-all)– Limits granularity of access control to few levels– Organized on a per-object or per-user basis– More flexible, but can be inefficient (implementation)

• Access Control Data Structures: – Access control list:

• contains all subjects who have access to object and their access. • Can have default permissions for different types of users (ugw)

– Access control matrix: • Each row represents subject• Each column represents object• Each entry contains set of access rights for <subj,obj>

R

R

RFile Protection (cont’d)

• Capability: unforgeable token/ticket giving certain rights to an object for holder.

• Basis for Kerberos (authentication system for dist. sys)• OS holds all tickets for users (one approach)

– Returns a ptr to OS data structure that also links to user– Capability only created by specific request from user to OS

• Each capability identifies allowable accesses.• When process executes in a domain/local name space

– Collection of objects that process has access to– During exec., if new objects are needed,

• OS checks if user has access• If yes, then generates a capability/ticket for that object.

• Capabilities stored in memory inaccessible by user:– Can use base/bound register or tagged arch.

R

R

RUser Authentication

• Serious issue with single, stand-alone machines• More serious with multiple (unfamiliar) users

– Traditional authentication: password• Plaintext password file very vulnerable• Heavily protected or encrypted

– Need to establish administrative procedures to make users’ passwords sufficiently secure

– May need more security protocols to perform mutual authentication in an untrusted environment

R

R

RAttacks on Passwords

1. Try all possible passwords:1. 8 chars: 261 + 262 + … 268 = 269 - 1 = 5* 1012

2. 1 pw/millisec 150 yrs; 1 pw/microsec 2 mos

2. Try many probable passwords:1. Long, uncommon, hard to spell/pronounce?2. PW of 3 chars=18,278 pw 18.278 secs3. PW of 4-5 chars only 8 mins and 3.5 hrs., resp.

3. Try passwords likely for a given user:1. Beer, birthdates, names, places

4. Search for system file containing passwords5. Ask the user

[Pfleeger97]

R

R

RAttacks on Passwords (cont’d)

• Klein (1990): 2.7% PW guessed in 15 mins of machine time; 21% guessed in a week

• Spafford (1992): avg PW length 6.8 chars, 28.9% had only lowercase chars

15 (0.5%) Single ASCII char

72 (2%) 2 ASCII char

464 (14%) 3 ASCII char

477 (14%) 4 alph char

706 (21%) 5 alph letters, same case

605 (18%) 6 LC alph letters

492 (15%) Words in dictionaries, lists of names

2831 (86%) Total of all above categories

[Pfleeger97]

[Morris and Thompson 79]

R

R

RPassword Lists

• Plaintext System Password list:– May protect with strong access controls (e.g.OS maintains)– Parts of OS need not have access (e.g., scheduler, acctg)

• If those are compromised, then PWs are accessible

• Encrypted Password file:– Conventional encryption:

• PW in password file is encrypted (PWF)• User logs in, system decrypts PWF, and compares• Plaintext PW is available briefly

– One-way encryption:• User logs in, system encrypts PW and compares to PWF• If PW file is accessible to public, then 2 people who have same PW can be

compromised.• UNIX: uses PW extension, salt (12-bit number: system time and process identifier):

E(PW+saltU)

R

R

RPassword Selection

• Use chars other than A-Z:– Use Upper/lowercase; digits– 100 hours to text all 6-char LC– 2 years to test 6-symbols (ul,ll, digits)

• Long passwords: 6 char or longer• Avoid real names/words

– 266 (300 M) 6-char words; 150,000 in dict

• Unlikely password: 2Brn2B• Change passwords regularly• Don’t write it down• Don’t tell anyone else

R

R

RAuthentication Process

• One-time password:– Uses challenge-response system: system

provides argument, user calculates math function: f(x)= x+1

• Purposefully slow authentication systems• Impersonation of Login• Non-password authentication:

– Biometrics: finger/handprint, retina, voice recog.

R

R

R

Designing Trusted OS

R

R

RMajor Activities

• Understand environment to be protected– Policies and models and their interactions

• Design system to provide desired protection– Similar principles to those used in SE

• Correctness of design and implementation– Verification, validation, penetration testing– Evaluation criteria std for certification

R

R

RFoundations of Trusted OS

• Policy: – security reqts are set of well-defined, consistent, and

implementable rules that have been clearly and unambiguously expressed.

• Model: – model of environment to be protected to fully understand

needs

• Design: means to implement model– Defines both what and how

• Trust: system will meet expectations– Features: all necessary functionality to enforce security policy– Assurance: confidence that the implementation will enforce

security policy

[Pfleeger97]

R

R

RSecure vs Trusted

[Pfleeger97]

Secure Trusted

Either-or: something is or is not secure

Graded: degrees of trustedness

Property of presenter Property of receiver

Asserted: based on product characteristics

Judged: based on evidence and analysis

Absolute: not qualified as to how, where, when, or by whom used

Relative: viewed in context

A goal A characteristic

R

R

RSecurity Policies

• Policy: statement of security expected to be enforced by system

• Review:– Military Security Policy

• Basis for much work in trusted OS • Focus on protecting classified information

– Commericial Security Policies:• Less rigid • Still have many similar concepts

R

R

RMilitary Security Policy

• Need-to-know rule:– For info access– Need to perform jobs

• Sensitivity of object O– rankO

• Each piece of classified info may be associated with more than one project (compartment)

• Compartments: – Cover info at 1 sensitivity level– Or include info from more than 1

• Classification of info: – < rank;compartments>

• Clearance:– Indication that person is trusted to access

info up to a sensitivity level

Topsecret

Secret

Confidential

Restricted

Unclassified

[Pfleeger97]

R

R

RCompartments and Sensitivity

• Dominance (• Relation on objects and subjects

– Subject s and object o: • s iff ranks rankO and compartmentss compartmentsO

• Limit sensitivity and content of info a subject can access.• Subject can read object if:

– A) subject clearance lvl at least as high as info– B) subject has need to know about ALL compartments for which info is

classified

• Military security enforce sensitivity and need-to-know reqts– Hierarchical reqts: sensitivity – Non-hierarchical: need to know restrictions

• Access is rigidly controlled by central body.

R

R

RCommercial Security Policies

• Less rigid than military policies• Still have objects to protect• Sensitivity levels:

– Public, proprietary, internal– Due more to projects

• No formal clearance policies• Access rules are less rigorous

– No dominance function– Manager can override access “rules”

R

R

RExample Policies

• Separation of duty:– Issue order, write check, receive goods

• Chinese wall security policy [Brewer and Nash 89]– Addresses commercial needs for info access protection– Domain: legal, medical, investment, or acctg firms with potential

conflict of interests• Objects: lowest level has elementary objects (files).

– Ea. File contains info about only one company

• Company groups: all info about each company clustered• Conflict classes: all groups of objects for competitors clustered.

– Access policy:• Person can access any info, if never accessed info from diff. Company in

same conflict class

R

R

RExample Chinese Wall

Nike

Reebok

Citibank

Wells Fargo

Bank One

Northwest

Nike

Reebok

Citibank

Wells Fargo

Bank One

Northwest

Initial accesses

After selecting Reebok and Bank One

R

R

RModels of Security

• Objective:– Test specific policy for completeness and

consistency– Document policy– Help conceptualize and design implementation– Check if implementation satisfies reqts

R

R

RMultilevel Security

• Lattice structure:– Ordered by relationship

• Bell-La Padula Confidentiality Model– Formal description of allowable paths of

info flow in secure system

R

R

RDesign of Trusted OS

R

R

RAssurance in Trusted OS