Thoughts on Client Systems Security Joanna Rutkowska Invisible - - PowerPoint PPT Presentation

thoughts on client systems security
SMART_READER_LITE
LIVE PREVIEW

Thoughts on Client Systems Security Joanna Rutkowska Invisible - - PowerPoint PPT Presentation

Thoughts on Client Systems Security Joanna Rutkowska Invisible Things Lab SSTIC 2011, Rennes, France, June 2011 Why client systems security is important? If your client device (laptop, tablet, phone) is compromised... ... all the security is


slide-1
SLIDE 1

Thoughts on Client Systems Security

Joanna Rutkowska Invisible Things Lab

SSTIC 2011, Rennes, France, June 2011

slide-2
SLIDE 2

Why client systems security is important?

slide-3
SLIDE 3

If your client device (laptop, tablet, phone) is compromised...

slide-4
SLIDE 4

... all the security is lost!

slide-5
SLIDE 5

Client systems are your eyes and fingertips The client OS can see what you see on the screen (decrypted) The client OS can pretend to be you

slide-6
SLIDE 6

Approaches to building secure (client) systems

slide-7
SLIDE 7
slide-8
SLIDE 8
slide-9
SLIDE 9
slide-10
SLIDE 10
slide-11
SLIDE 11

Security by Isolation: Goals

slide-12
SLIDE 12

App1 App2

? Isolation between two apps...

slide-13
SLIDE 13

App1 App2

Isolation between two apps...

slide-14
SLIDE 14

App1 App2 TCB (OS)

Isolation between two apps and the OS...

slide-15
SLIDE 15
slide-16
SLIDE 16

GUI-level isolation

slide-17
SLIDE 17

Lack of GUI isolation on many Windowing Systems...

slide-18
SLIDE 18

App1 App2 Sniff keystrokes Take screenshots Inject keystrokes

slide-19
SLIDE 19

Fat GUI APIs that are likely to be buggy (and exploitable)

slide-20
SLIDE 20

GUI API (Xlib, OpenGL, ...) App1 App2 GPU

slide-21
SLIDE 21

Work email Tetris

slide-22
SLIDE 22

Bank Browser Personal Browser

slide-23
SLIDE 23

We don't want two apps to be able to interact with each other via X/OpenGL/GPU! (Xorg people still don't get it, after 20+ years...)

slide-24
SLIDE 24

Anyway...

slide-25
SLIDE 25

Let's imagine we implemented strong isolation...

slide-26
SLIDE 26

We still must allow the user to bypass it sometimes!

slide-27
SLIDE 27

Data flows between domains

Clipboard File sharing

slide-28
SLIDE 28

Down-transfers vs. Up-transfers

slide-29
SLIDE 29

App1 App2

Trust level "Up Transfer"

slide-30
SLIDE 30

App1 App2

Trust level "Down Transfer"

slide-31
SLIDE 31

"Traditional" school of thought:

Never allow down-transfers!

Even between two cooperating domains!

slide-32
SLIDE 32

Rationale: never allow to move more sensitive data (e.g. Embassy cables) to less trusted domain (e.g. The Internet)

slide-33
SLIDE 33

App1 App2

Malware Malware

Data

OS should never allow for this flow!

slide-34
SLIDE 34

This requires elimination/drastic reduction of all potential cooperative covert channels between the apps/domains!

slide-35
SLIDE 35

I seriously doubt this is possible on modern x86 hardware...

slide-36
SLIDE 36

Covert channels via CPU cache Covert channels via GUI/GPU Covert channels via networking Covert channels via other subsystems ?

slide-37
SLIDE 37

"Qubes" school of thought:

Avoid up-transfers!

slide-38
SLIDE 38

Rationale: an up-transfer can potentially compromise a buggy app in the destination domains (untrusted input processing)

Work domain

Compromised app/domain

Malformed JPEG Buggy JPEG parser

slide-39
SLIDE 39

Some up-transfers are difficult to avoid...

slide-40
SLIDE 40

Copying a link found on the Internet, and emailing it to a colleague at work

slide-41
SLIDE 41

Copying a cool cartoon found on the Internet into work confidential report/presentation

slide-42
SLIDE 42

Solution: use trusted converters, e.g. for all JPEGs?

slide-43
SLIDE 43
slide-44
SLIDE 44

Another types of problems related to file sharing is FS Metadata parsing

slide-45
SLIDE 45

Machine 1 Machine 2

Two air-gapped systems

slide-46
SLIDE 46

Machine 1 Machine 2

Two air-gapped systems

Copying data using USB stick

slide-47
SLIDE 47

Machine 1 Machine 2

Two air-gapped systems

The sticks partition table turned out to be malformed...

Exploit

slide-48
SLIDE 48

In Qubes we copy files between domains using shared memory and simple cpio-like tool (this cpio-like tool is the security critical code)

slide-49
SLIDE 49

Limitations of Security by Isolation approach

slide-50
SLIDE 50

Security by Isolation doesn't protect your apps from being compromised!

slide-51
SLIDE 51

Work email Random Web browsing

slide-52
SLIDE 52

Mail server Work email Random Web browsing Exploiting hypothetical bug in my email client's OpenSSL

slide-53
SLIDE 53

Mail server Work email Random Web browsing Exploiting hypothetical bug in my email client's OpenSSL MTIM

slide-54
SLIDE 54

My recent adventure in a hotel in Paris ;)

slide-55
SLIDE 55

Solution: decompose the app! (More security by isolation!)

slide-56
SLIDE 56

Email parsing GPG OpenSSL handling

Capsicum is working on such app-level decompositions (will definitely use in Qubes when ready)

slide-57
SLIDE 57

Another approach: safe languages (so, where can I get thunderbird-like app written in C#?)

slide-58
SLIDE 58

Security by Isolation: Useful technologies

slide-59
SLIDE 59

Technologies for address space isolation MMU Virtualization (VT-x/AMD-v, EPT/NPT)

slide-60
SLIDE 60

MMU VT-x/EPT User mode (ring 3) Guest mode (non-root) Kernel mode (ring 0) Hypervisor (root mode) Page Tables Extended Page Tables (EPT) Exceptions (#GP, #PF, ...) VM exits

Analogies

slide-61
SLIDE 61

MMU VT-x/EPT User mode and kernel mode often share the same address space (e.g. 3/1GB split on 32bit Linux) Guest and the hypervisor never share the same address space SIPI interrupts kernel execution SIPI is blocked in VMX

Differences

SMEP somehow eliminates this difference Interrupt Remapping makes this irrelevant anyway

slide-62
SLIDE 62

So, why bother using virtualization? Why not just use the good old MMU for address space isolation?

slide-63
SLIDE 63

For compatibility with OSes that are not para-virtualizable Windows Mac OSX

Linux is PV aware and we can virtualize it using MMU under Xen (Run it as ring3, no need for VT-x)

slide-64
SLIDE 64

But why would we want to virtualize the OS in the first place?

A virtualized buggy, messy OS is still... a buggy, messy OS!

slide-65
SLIDE 65

Because we want to use the OS as an API provider!

slide-66
SLIDE 66

App1 App2 TCB (OS) App3 USB stacks Networking stacks File systems GUI Everything and the kitchen sink!

A P I ( e . g . P O S I X ) A P I ( e . g . P O S I X ) A P I ( e . g . P O S I X )

slide-67
SLIDE 67

App1 App2 TCB (microkernel/hypervisor) App3 Networking Drivers & stacks Storage drivers and backends (block, pvusb)

Backend Backends

GUI

Backend

But those (legacy) apps expect a POSIX API, they don't know how to talk to the backends Untrusted subsystems CPU scheduling, MMU & IOMMU only

slide-68
SLIDE 68

So we must virtualize the whole OS to provide API for legacy apps...

slide-69
SLIDE 69

App1 TCB (microkernel/hypervisor) Networking Drivers & stacks Storage drivers and backends (block, pvusb)

Backend Backends

GUI

Backend

Untrusted subsystems App2 App3

Domain 1 Domain 2

Apps see POSIX APIs

Frontends Frontends

NICs SATA, USB GPU, keyboard

slide-70
SLIDE 70

But it is not like virtualization (VT-x) provides stronger security than MMU!

slide-71
SLIDE 71

IOMMU (VT-d)

slide-72
SLIDE 72

IOMMU allows to sandbox drivers and devices, so plays a key role in TCB disaggregation...

slide-73
SLIDE 73

App1 TCB (microkernel/hypervisor) Networking Drivers & stacks Storage drivers and backends (block, pvusb)

Backend Backends

GUI

Backend

Untrusted subsystems App2 App3

Domain 1 Domain 2

Frontends Frontends

NICs SATA, USB GPU, keyboard IOMMU/VT-d

slide-74
SLIDE 74

IOMMU: catches

slide-75
SLIDE 75

For safe language-based OSes (e.g. Singularity and derivatives) IOMMU is needed to restrict devices to accesses to their DMA buffers only to preserve memory safety

slide-76
SLIDE 76

Catches: MSI attacks BDF Spoofing Reflashing device firmware?

Interrupt Remapping

(see our latest paper on VT-d escapes)

PCIe ACS DMA-resistant trusted boot

slide-77
SLIDE 77

We really need more trusted trusted boots! (subject for another presentation)

slide-78
SLIDE 78

No secure client systems without IOMMU and trusted boot!

slide-79
SLIDE 79

Security by Isolation: Challenges

slide-80
SLIDE 80

How to partition my digital life into security domains?

slide-81
SLIDE 81

Do we actually need domains? Perhaps we can just isolate each app from each other app? We need OSes to provide legacy APIs to apps Would be a waste of memory to have one instance of an OS per each app...

slide-82
SLIDE 82

But even if we did isolate (virtualize?) on a per app granularity, still the problem of partitioning doesn't go away...

slide-83
SLIDE 83

Mail

slide-84
SLIDE 84

Mail Personal Mail Work

slide-85
SLIDE 85

Unless we get 100% safe languages we would not avoid security by isolation...

slide-86
SLIDE 86

Other challenges

slide-87
SLIDE 87

GPU multiplexing

slide-88
SLIDE 88

USB multiplexing

slide-89
SLIDE 89

I'd love to discuss that last two problems!

slide-90
SLIDE 90

Qubes OS implements lots of ideas mentioned here

slide-91
SLIDE 91
slide-92
SLIDE 92
slide-93
SLIDE 93
slide-94
SLIDE 94

Qubes is not a microkernel.... ... It's everything else!

slide-95
SLIDE 95

Qubes-OS.org

slide-96
SLIDE 96

Thanks!