Lecture 16 Overview

1
Lecture 16 Overview
2
Targeted Malicious Code

• Trapdoor
• undocumented entry point to a module
• forget to remove them
• intentionally leave them in the program for
  testing
• intentionally leave them in the program for
  maintenance of the finished program, or
• intentionally leave them in the program as a
  covert means of access to the component after it
  becomes an accepted part of a production system

3
Targeted Malicious Code

• Salami Attack
• a series of many minor actions that together
  results in a larger action that would be
  difficult or illegal to perform at once
• Ex. Interest computation
• rootkit
• A program or coordinated set of programs designed
  to gain control over a computer system or network
  of computing systems

4
Targeted Malicious Code

• Privilege Escalation
• a means for malicious code to be launched by a
  user with lower privileges but run with higher
  privileges
• Interface illusion
• a spoofing attack in which all or part of a web
  page is false
• Keystroke Logging

5
Targeted Malicious Code

• Man-in-the-Middle Attacks
• Timing Attacks
• attempts to compromise a cryptosystem by
  analyzing the time taken to execute cryptographic
  algorithms
• Covert Channels
• programs that leak information
• Ex. Hide data in output

6
Covert Channel

• Two active agents
• Sender (has access to unauthorized information)
• e.g., Trojan Horse in MS Word
• Receiver (reads sent information)
• e.g., program creating the copy
• Encoding schema
• How the information is sent
• e.g.,
• File F exists ? 0
• File F is does not exist ? 1
• Synchronization
• e.g., when to check for existence of F

7
Storage Covert Channels

• Based on properties of resources
• pass information by using presence or absence of
  objects in storage
• Examples
• File locks
• Delete/create file
• Memory allocation

8
Timing Covert Channel

• Time is the factor how fast
• pass information using the speed at which things
  happen
• Examples
• Processing time
• Transmission time

9
Controls Against Program Threats

• Prevent Threats during software development
• Modularity
• security analysts must be able to understand each
  component as an independent unit and be assured
  of its limited effect on other components

10
Controls Against Program Threats

• Prevent Threats during software development
• Encapsulation
• hide a component's implementation details
• minimize interfaces to reduce covert channels
• Information hiding
• a component as a kind of black box
• components will have limited effect on other
  components

11
Controls Against Program Threats

• Peer Reviews
• Hazard Analysis
• set of systematic techniques to expose
  potentially hazardous system states
• Testing
• unit testing, integration testing, function
  testing, performance testing, acceptance testing,
  installation testing, regression testing

12
Controls Against Program Threats

• Good Design
• Using a philosophy of fault tolerance
• Have a consistent policy for handling failures
• Capture the design rationale and history
• Use design patterns
• Prediction
• predict the risks involved in building and using
  the system

13
Controls Against Program Threats

• Static Analysis
• Use tools and techniques to examine
  characteristics of design and code to see if the
  characteristics warn of possible faults
• Configuration Management
• control changes during development and
  maintenance
• Analysis of Mistakes
• Proofs of Program Correctness
• Can we prove that there are no security holes?

14
Operating System Controls on Use of Programs

• Trusted Software
• code has been rigorously developed and analyzed
• Functional correctness
• Enforcement of integrity
• Limited privilege
• Appropriate confidence level

15
Operating System Controls on Use of Programs

• Mutual Suspicion
• assume other program is not trustworthy
• Confinement
• limit resources that program can access
• Access Log
• list who access computer objects, when, and for
  how long

16
Administrative Controls

• Standards of Program Development
• Standards of design
• Standards of documentation, language, and coding
  style
• Standards of programming
• Standards of testing
• Standards of configuration management
• Security Audits
• Separation of Duties

17
Lecture 17Protection in Operating System

• CS 450/650
• Fundamentals of
• Integrated Computer Security

Slides are modified from Ian Goldberg and Hesham
El-Rewini
18
Operating System

• An OS allows different users to access different
  resources in a shared way
• The OS needs to control
• the sharing and
• provide an interface to allow the access
• Identification and authentication are required
  for access control

19
History

• OSs evolved as a way to allow multiple users use
  the same hardware
• Sequentially (based on executives)?
• Interleaving (based on monitors)?
• OS makes resources available to users
• if required by them and permitted by some policy
• OS also protects users from each other
• Attacks, mistakes, resource overconsumption
• Even for a single-user OS, protecting a user from
  him/herself is a good thing
• Mistakes, malware

20
Protected Objects

• CPU
• Memory
• I/O devices (disks, printers, keyboards,...)?
• Programs
• Data
• Networks

21
Separation

• Keep one user's objects separate from other users
• Physical separation
• Use different physical resources for different
  users
• Easy to implement, but expensive and inefficient
• Temporal separation
• Execute different users' programs at different
  times

22
Separation

• Logical separation
• User is given the impression that no other users
  exist
• As done by an operating system
• Cryptographic separation
• Encrypt data and make it unintelligible to
  outsiders
• Complex

23
Sharing

• Sometimes, users want to share resources
• Library routines (e.g., libc)?
• Files or database records
• OS should allow flexible sharing, not all or
  nothing
• Which files or records? Which part of a
  file/record?
• Which other users?
• Can other users share objects further?
• What uses are permitted?
• Read but not write, view but not print
  (Feasibility?)?
• Aggregate information only
• For how long?

24
Memory and Address Protection

• Prevent program from corrupting other programs or
  data, operating system and maybe itself
• Often, the OS can exploit hardware support for
  this protection, so its cheap
• Memory protection is part of translation from
  virtual to physical addresses
• Memory management unit (MMU) generates exception
  if something is wrong with virtual address or
  associated request
• OS maintains mapping tables used by MMU and deals
  with raised exceptions

25
Memory and Address Protection
Bare Machine
0
user
memory
n
26
Protection Techniques

• Fence register
• Exception if memory access below address in fence
  register
• Protects operating system from user programs
• Single user only

27
Address Protection for a resident monitor
0
Fence register
memory
CPU
address
Address gt fence
true
false
n
error
28
Protection Techniques

• Base/bounds register pair
• Exception if memory access below/above address in
  base/bounds register
• Different values for each user program
• Maintained by operating system during context
  switch
• Limited flexibility

29
Protection Techniques

• Tagged architecture
• Each memory word has one or more extra bits that
  identify access rights to word
• Very flexible
• Large overhead
• Difficult to port OS from/to other hardware
  architectures
• Segmentation
• Paging

30
Other Issues

• Multiprogramming
• Multiple users
• Relocation
• Segmentation, paging, combined

31
Segmentation

• Each program has multiple address spaces
• Segments
• use different segments for code, data, stack
• Or maybe even more fine-grained,
• different segments for data with different access
  restrictions
• Virtual addresses consist of two parts
• ltsegment name, offset within segmentgt

32
Segmentation

• OS keeps mapping from segment name to its base
  physical address in Segment Table
• OS can transparently relocate or resize segments
  and share them between processes
• Each segment has its own memory protection
  attributes

33
Segmentation
Segment Table
limit
base
0
memory
CPU
(s,d)
lt
true

false
n
error
34
Logical and Physical Representation of Segments
35
Translation of Segment Address
Segment Table also contains memory protection
attributes
36
Review of Segmentation

• Advantages
• Each address reference is checked for protection
  by hardware
• Many different classes of data items can be
  assigned different levels of protection
• Users can share access to a segment, with
  potentially different access rights
• Users cannot access an unpermitted segment

37
Review of Segmentation

• Disadvantages
• External fragmentation
• Dynamic length of segments requires costly
  out-of-bounds check for generated physical
  addresses
• Segment names are difficult to implement
  efficiently

38
Paging

• Program (i.e., virtual address space) is divided
  into equal-sized chunks
• pages
• Physical memory is divided into equal-sized
  chunks
• frames
• Frame size equals page size

39
Paging

• Virtual addresses consist of two parts
• ltpage , offset within pagegt
• bits for offset log2(page size),
• no out-of-bounds possible for offset
• OS keeps mapping from page to its base physical
  address in Page Table
• Each page has its own memory protection attributes

40
Paging
Page Table
f
0
memory
CPU
p
d
f
d
Logical address
Physical address
n
41
Page Address Translation
42
Review of Paging

• Advantages
• Each address reference is checked for protection
  by hardware
• Users can share access to a page, with
  potentially different access rights
• Users cannot access an unpermitted page
• Disadvantages
• Internal fragmentation
• Assigning different levels of protection to
  different classes of data items not feasible

43
x86 Architecture

• x86 architecture provides both segmentation and
  paging
• Linux uses a combination of segmentation and
  paging
• Only simple form of segmentation to avoid
  portability issues
• Segmentation cannot be turned off on x86
• Same for Windows

44
Paged Segmentation
45
x86 Architecture

• Memory protection bits indicate no access,
  read/write access or read-only access
• Recent x86 processors also include NX (No
  eXecute) bit, forbidding execution of
  instructions stored in page
• Enabled in Windows XP SP 2 and some Linux distros
  
• Helps against some buffer overflows