Controlling a Computer Richard Newman

1. Controlling a ComputerRichard Newman

2. Computer Components Motherboard • CPU • RAM/daughterboards • CMOS • ROM with BIOS • I/O circuits, connectors Power Supply Peripherals • Keyboard • Monitor/video • Mouse • Drives • Network Interface(s)

3. Program Execution - Fetch-decode-execute cycle • Fetch instruction from RAM using Program Counter • Load into Instruction Register • Decode instruction in IR • Execute instruction in IR • Load additional operand(s) into data register(s) • Set PC to next instruction depending on length • Perform actual instruction - Process Image • Text segment (code/control) • Data (heap) segment (alloc'ed memory and globals) • Usually grows “upward” toward stack • Stack (dynamic – procedure calls) • Usually grows “downward” toward heap

4. Hardware Protection - Tagged Memory • Owner • Data/instructions • Read/write access - Protected Instructions • Mode bit(s) • Must be in proper mode to execute certain insructions • Protects raw I/O, clock, memory access, etc. - Virtual Memory • User processes general logical addresses • LA converted to physical address by MMU/memory map • Prevents one process from generating physical address that does not belong to it • Access to non-local memory through system calls

5. Buffer Overflow Buffers • Memory locations used for transferring data • Often data multiply handled to adjust for variable speed/bursts or for efficiency reasons Process makes procedure call • Activation frame is pushed onto the stack • PC set to first instruction of called procedure • When procedure done, return to next instruction of caller Activation Frame • Return address of calling procedure • Parameters passed in (set by caller) • Results passed out (set by called routine) • Local variables (declared in called procedure) If called procedure does not limit length of input, can overwrite parts of AF in stack

6. Buffer Overflow - 2 If called procedure does not check length of input read into buffer, can overwrite return PC value PC value can be set to point to location in stack (not code segment) Location pointed to by new PC value can hold attack code (e.g., shell script) Code is executed with access levels of process that made call with buffer overflow -> Counter measures - check/limit length of read buffers - tagged memory (don't execute stack locations) - least privilege

7. Access Control Strategies - Islands • Isolation and mediation • Untrusted process given “sandbox” - Vaults • Access to wider (more dangerous) resources requested individually with system mediation on a case-by-case basis • Required for access to shared resources - Puzzles • Process uses secret or hidden information to access desired resources – must be impractical to find it or to guess • Cryptography, steganography, security through obscurity - Patterns • Access patterns compared with known bad patterns, blocked or audited if match (virus signatures) • Normal access patterns noted and deviations detected (anomalies)

8. Chain of Control When computer starts, it runs software that enforces desired security policy Other software started either • Complies with security policy, or • Is prevented from violating the policy by system restrictions and/or mediation Subversion of CoC • Boot from different source (e.g., CD-ROM) • Trojan Horse (get user/admin to execute attack code) • Attack process vulnerability (force legit process to execute attack code – e.g., buffer overflow)

9. OS Security Features CPU scheduling • Prevent “hogging” CPU • Kernel mode context switch to isolate process execution Isolate memory allocation to processes and protect • Fence • Base/Bounds • Virtual Memory – page/segment table Isolate I/O to/from processes • Ptty's, exclusive access Process authorization based on owner ID • User I&A • Process “protection domain” to decide access Audit • Log “interesting” events

10. Access Control Shared Resources • CPU(s) – serially shared • Memory – may have concurrent access or serial re-use • Devices – access through service processes Shared Memory • Easiest with Segmented Memory • Multiple process segment tables have entry pointing to same memory segment • Most often for read-only segments (e.g., text) • Can also be used for shared data segments – race conditions Access rights implementation/enforcement • In segment table – set up as read-only • Via Access Matrix

11. Access Control Matrix Conceptual model for access control specification • Rows - “domains” or processes • Columns - “objects” - including (passivated) processes • Cells – define access rights domain has for object ACM State • Defined by contents of ACM cells and ACM dimensions • State change by • Add/remove object • Add/remove domain/process • Add/remove right from cell [i,j] • Request for access mediated through RM consulting ACM • RM follows guarded commands as part of system HRU Undecidability • From initial state, can a state be reached with r in ACM[i,j]? • Undecidable via TM simulation

12. Access Control Matrix - 2 ACM is too large • Domain may include <ruid, rgid, euid, egid> or more • Objects include all files, devices, may be sub-file level • Inescapable Mediation requires checking each time • ACM too big for RAM!!! ACL – access control lists • “Column” of ACM – associated with object • (domain, rights-set) pairs • Bring ACL into RAM along with object control block • Only need ACLs for actively used objects CL – capability lists • “Row” of ACM – associated with domain or process • (object, rights-set) pairs • Only need CLs for active processes

13. Access Control Matrix - 3 Hybrid approach • ACL used to decide access rights on OPEN of object • Capability added to CL of process during OPEN • Don't have to populate CL for all possible objects • Can limit access for process to least privilege Time-of-check to time-of-use problem • Access rights checked at one time • Nature of object changes before use (the old switcheroo) • Need (implicit) capability “locked” for object and CL

14. Security Policy and Implementation Policy = What you want Implementation = What you get • Every system has both, whether known or not Model = Means of expression of set of policies • Mathematical • Graphical • Transactional Model constraints expressability of policies Implementation constrains enforceability of policies

15. Writing a Security Policy 1. Each statement is numbered (allows cross-referencing) • May be outline numbered if complicated 2. Each statement uses the word “shall” • “may” used for optional parts • “should” used for optional but only if strong reasons for not doing 3. Policy statements should be testable • Determine if implementation enforces policy for compliance 4. Each statement identifies prioritized risks it addresses 5. Statements should state policies positively (i.e., “do this”) • Avoid negative (“Don't do that”) - hard to test • Avoid global (“all, any”) - hard to test • May not always be possible

16. Security Control Categories Physical • Physical boundaries that resist penetration – e.g., wall, door, Faraday cage, etc. Mechanical • Protection from connections that can be changed only through mechanical intervention – e.g., unplugging network cable Logical • Structured rules enforced by program, e.g., rwx bits Functional • Design and operation of functions in s/w, e.g., s/w tests for condition Procedural • Explicit operating procedures for humans, e.g., key distribution Cryptographic • Cryptographic transformation of data/code

17. Implementation: Security Control List Number each control • As with policies Specify control category • Clarify its nature Describe control • What it is • Configuration • How to use Relationship to policy • cross-reference

18. Checking Policy, Controls Verify each risk has one or more associated policies Review policies associated with each risk to assure coverage Verify each policy has associated controls Review controls associated with each policy to assure adequate enforcement If controls are incomplete for policy, expand controls