Influential OS Research Security. Michael Raitza

Size: px

Start display at page:

Download "Influential OS Research Security. Michael Raitza"

Homer Lee
5 years ago
Views:

1 Influential OS Research Security Michael Raitza 1

2 Security recap Various layers of security Application System Communication Aspects of security Access control / authorization Guarantee of service / availability Identification / authentication, verification 2. 1

3 Capabilities First described in [ Dennis, Horn 1966] Represent an access permission of some kind for some data Are itself data Managed by the system Cannot be forged by the process Attached to a process (might be shared) Modern capabilities Can be shared between processes, transfered, inherited A capability is an unforgeable (immutable) token (piece of data) of authentication for some system resource possessed by a process. Possession itself grants access. 3. 1

4 Access control lists (ACL) Mapping of identifiers to access rights Attached to objects to be accessed Managed by the system Not directly seen by the process cannot be forged Checked on access by the enforcing system An ACL is an out-of-process entity that allows to control access to some system resource. Access is granted after proactive checking by the enforcing system. 4. 1

5 Role-based access control Programs always work in a role Program can drop to a lower role but not elevate to a higher role Higher role programs start lower role programs Roles can be selectively inheritable SELinux every program effectively needs a policy huge maintenance burden and/or trust in vendor/distributor supplied policies needed 5. 1

6 Processor Modes Invented for MULTICS to enable multiprogramming environment Idea of rings of priviledge that hold CPU instructions Inner rings can use instructions in the outer rings but not vice versa Allows to implement memory protection via hardware enforced addressing schemes 6. 1

7 Processor Modes (cont'd) Intel IA64 defines several modes (from least to most privileged) User mode Kernel mode Hypervisor mode SMM mode SGX mode 7. 1

8 Memory Protection Schemes Paged virtual memory Segmented virtual memory Capability-based addressing 8. 1

9 Paging First implemented in the Atlas Computer (1959/62), but also in IBM System/370, Intel IA-32 (since 80386) Hierarchical database of per process registered pages in page table First (and sometimes second) level called page directory that holds page tables 2 (3) protection domains (VM) / Kernel / Userspace Page sizes of limited variability Normally 1 or 2 like 4 kb normal page and 128 MB super page 9. 1

10 Processor must support pagefault exceptions that can be chained with other exceptions Practically necessary: Translation lookaside buffer that act as page cache Nested paging Processor traps on page faults enables lazy management OS manages page tables Physical data layout and current consumption invisible to process 10. 1

11 Segmentation First implemented in the Burroughs B5500, but also in MULTICS, IBM System/38, Intel Flat (virtual) address space partitioning Works in principle w/o virtual addressing Addresses relate to a segment base Segment base must be loaded before access Memory segmentation visible to the process RAM and Filesystem address spaces can be merged Fully automatic (no user process interaction) memory management possible 11. 1

12 Capability-based addressing No free pointer operation in userspace Form of object-based addressing Every access to memory referenced through a capability No address space separation necessary no context switches Possible implementations: Store capabilities in protected memory area, modify through privileged process Extend memory by capability bit to mark protected locations 12. 1

13 Intel SGX Selective encryption up to the CPU's physical chip package CPU is the only physical unit with access to clear text Not even physical access to system reveals secrets Provided the chip is not tampered with Pros: High-speed cryptographic functions Provides trust in an untrusted OS environment Cons: Fixed cryptographic functions with fixed parameters SHA-256 (attestation / measurement) RSA-3072 (long term keys, signing) AES-128 (data encryption) Extremely complex architecture and mechanisms 13. 1

14 Intel SGX Trust model Data owner (Owen) has local secure platform to control and verify computation Software author (Sofia) enables communication between local and remote computers and must be trusted Remote secure container software manages sensitive data Infrastructure owner (Ivy) offers remote platform but must not be trusted But must give some guarantee of service Manufacturer (Manfred) builds the trusted computing platform including cryptographic primitives see: Intel SGX Explained. Victor Costan and Srinivas Devadas, Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology,

15 Trust relation Owen Sofia Ivy Manfred Owen T (T) T Sofia T T Ivy T T Manfred To get rid of transitive trust from Owen to Ivy Keys must be provided by Manfred Secure Container must be signed and measured by Manfred's keys trusted booting, breaks trust from Sofia to Ivy Intel (Manfred) expects each participant (Owen and Sofia) to derive their keys from Intel's master key 14. 2

16 Intel SGX Attestation Proof is a signed message that covers data from both sides The channel to transmit g(a) and g(b) must be secured as it does not guarantee integrity The attestation key must be trusted Intel SGX Explained

17 ARM TrustZone Extension to address bus by one bit to indicate secure access Attached hardware must be capable to handle the secure bit to be TrustZone aware Secure World stored entirely in a separate secure SRAM Intel SGX Explained

18 Weaknesses compared Attack Intel SGX ARM TrustZone Malicious 2nd container (cache timing) Malicious OS (page fault recording) Malicious OS (cache timing) x x x x N/A (Secure world part of TCB) Secure world has own set of page tables Physical DRAM address reads x Secure world in on-chip SRAM Intel SGX Explained. All containers are trusted in TrustZone Secure world of TrustZone must fit into SRAM might limit usability SGX cannot limit access to DRAM address reads (no on-chip SRAM) 17. 1

19 Singularity Research OS from Microsoft Based on the concept of managed code Microkernel encompasses I/O manager Scheduler Page manager Garbage collector Channel manager Kernel runs in real mode Kernel written in Sing# Separate hardware abstraction layer that runs in protected mode Process are implemented as software-isolated processes (SIP) 18. 1

20 Singularity Sing# C# delivers memory management the memory model garbage collection Spec# supports design by contract like Eiffel Sing# adds typesafe channels and low-level constructs to support OS development 19. 1

21 Singularity Software-isolated process Written in Sing# (an extension of Spec# an extension of C#) Runs in the same address space as kernel Protection provided by a set of invariants that can be statically analyzed Sing# provides necessary language properties no memory cross-references between SIPs no arbitrary pointers implicitly managed memory and garbage collection All communication done via channels according to contracts 20. 1

22 Singularity Software delivery Software delivered in Common intermediate language (CIL), the human-readable intermediate language of C# Installation done using OS support OS compiles CIL code to native x86 code using the Bartok compiler OS analyzes and verifies contracts of SIPs during compilation to establish security invariants 21. 1

23 Problems of contemporary security models Pointer values in native code are: Only coarsely unchecked Only protected by canaries (only return values, canary can be guessed) Do not abide to an inherent pointer validity model Can have arbitrary values Return instruction allows jumping to an arbitrary address Processes must trust themselves Can write into their own address space Alleviated by NX page table bit or write XOR execute semantics, respectively Commodity OSes are vulnerable to return-oriented programming (ROP) 22. 1

24 ROP explained The problem: Process image consists of a multitude of executable pages from Application's binary Loaded shared libraries dlopen()'ed libraries (e.g. plugins) OS loads whole library and not only the used functions many instruction sequences that can be used out of context sequences do not abide to stack discipline 23. 1

25 ROP mechanics Circumvent write XOR execute by returning to a known location return to libc attack Return address lead to jumps to gadgets performing a little work (1 3 instructions) Stack contains Data arguments Chain of addresses to return to gadgets 24. 1

26 Example Load constant into register Stack 0x00COFFEE <RETADDR> ESP ret <RETADDR>: pop %edx ret EDX 0x00COFFEE 25. 1

27 Example Add 23 to EAX Stack <l-4> <ptr to '23'> <l-3> <l-1> <l-2> 23 ESP <l-1>: ret <l-2>: pop %edi ret <l-3>: pop %edx ret <l-4>: addl (%edx), %eax push %edi ret 26. 1

28 Preventing ROP Randomize the library layout using ASLR Functions within one library still have the same relative layout Re-link the library at every boot Recently suggested by OpenBSD Save all objects to be linked and re-link in random order Link time in the order of seconds 27. 1

INFLUENTIAL OPERATING SYSTEM RESEARCH: SECURITY MECHANISMS AND HOW TO USE THEM CARSTEN WEINHOLD

Faculty of Computer Science Institute of Systems Architecture, Operating Systems Group INFLUENTIAL OPERATING SYSTEM RESEARCH: SECURITY MECHANISMS AND HOW TO USE THEM CARSTEN WEINHOLD OVERVIEW Fundamental