Matthew Garrett
Security in the modern world
- 2013 was an interesting year
- UEFI Secure boot was deployed to the masses. On most PCs by default
- ..and vendor implementations promptly broken
- Snowden revelations
- First highly visible hypervisor related compromise?
- ..no it turns out
- Who are we protecting against?
- The NSA?
- Our Hosting providers?
- Opportunistic attackers?
- Imperfect security is better than no security
- NSA
- Leaked material is from 2007-2008 so don’t know how is advanced
- No evidence that the entire stack has been subverted
- Leaked material describes model-specific (rather than vendor-specific) exploits
- Plausible that the vendors aren’t actively involved
- although passive involvement is likely
- Would it be in anyone’s interest to have a generic exploit?
- Intelligence agencies are probably not your biggest concern
- Most security compromises are either political or profit driven
- But that doesn’t make the user feel better
- What can we do to protect users
- Protecting the entire chain
- Boot verification is an absolute requirement
- OS’s are just too big to be perfect
- Persistent infections (of boot process) make recovery impractical
- …but so is user freedom
- Stopping users from building/booting their own kernels is not a good long term situation
- …ideally including the firmware
- Boot verification is an absolute requirement
- Where do we stand
- UEFI Secure boot on x86 systems
- Guaranteed that user can replace keys
- No guaranteed that the user can replace the fireware
- Andriod
- Primary compute device for many
- Some permit the user to replace the OS
- No ability to replace keys or fireware – cannot boot your own signed kernels
- Need to push vendors to provide replacement of OS and keys
- Apple
- No ability to replace OS, keys or fireware
- UEFI Secure boot on x86 systems
- How much can I trust my system
- OS backdoors
- Doesn’t really seem necessary, too many holes already
- Firmware backdoors
- Why has nobody audited the Jetway (leaked BIO and fireware) leak?
- Lower Level?
- AMT, CPU microcode
- AMT has a lot of access to running and even turned off systems, Intel would be greatly embarrassed
- CPU Microcode – could be updates by OS-level exploit
- It’s fine, all my data is in the cloud
- What even *is* the cloud
- If you are giving you data to someone else you are trusting them not to lose it or steal it
- …History suggest this is not a good idea
- But this is still a spectrum
- Running you server means you trust all your software
- Running a VM means you need to trust the hypervisor and other guests
- ..do you trusts those guests .. do you trusts those guest will be unable to compromise the hypervisor
- Questions to ask you cloud providers
- What secuity to isolates guests? selinux over kvm perhaps?
- How do you manage hypervisor updates in response to security issues?
- my mechanisms do you have to detect compromises to the hypervisor?
- what is your response to to finding a compromised device?
- Can you trust them at all?
- Introspection of the bare metal is hard
- Introspection of VMs is trivial
- Virtualisation requires different security considerations than bare metal requirements, more attacks
- OS backdoors
- Security in 2014
- Be more agressive about securing every layer of systems
- .. but do so in a way that ensures users don’t have to choose between freedom and security
- Start asking cloud vendors hard questions
- … and their customers, too
- Security and free are two sides of the same coin
- Don’t buy into any narrative that asks you you to give up one for the other