Lecture 16 Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lecture 17 Protection in Operating System CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Ian Goldberg and Hesham El-Rewini

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

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

Protected Objects CPU Memory I/O devices (disks, printers, keyboards,...)‏ Programs Data Networks

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

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

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?

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

Memory and Address Protection Bare Machine user memory n

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

Address Protection for a resident monitor Fence register memory CPU address Address >= fence true false error n

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

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

Other Issues Multiprogramming Multiple users Relocation Segmentation, paging, combined

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>

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

Segmentation + < memory Segment Table CPU (s,d) true false n error limit base memory CPU (s,d) < true + false n error

Logical and Physical Representation of Segments

Translation of Segment Address Segment Table also contains memory protection attributes

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

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

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

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

Paging memory Page Table CPU Logical address Physical address n f p d memory CPU p d f d Logical address Physical address n

Page Address Translation

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

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

Paged Segmentation

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