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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

6. Covert Channel Two active agents Encoding schema Synchronization
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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

8. Timing Covert Channel Time is the factor – how fast Examples:
pass information using the speed at which things happen
Examples:
Processing time
Transmission time
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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?
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

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
CS 450/650 Lecture 16: Targeted Malicious Codes

17. Lecture 17 Protection 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 Cryptographic 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 it’s 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
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
Fence register
memory
CPU
address
Address
>=
fence
true
false
error n

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:
<segment name, offset within segment>

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 + < memory Segment Table CPU (s,d) true false n error
limit
base
memory
CPU
(s,d)
<
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:
<page #, offset within page>
# 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 memory Page Table CPU Logical address Physical address n f p d
memory
CPU p d f d
Logical address
Physical address n

41. Page Address Translation

42. Review of Paging Advantages: Disadvantages:
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