Jun 11, 2018 by Joanna Rutkowska
A few months ago, during my keynote at Black Hat Europe, I was discussing how we should be limiting the amount of trust when building computer systems. Recently, a new technology from Intel has been gaining popularity among both developers and researchers, a technology which promises a big step towards such trust-minimizing systems. I’m talking about Intel SGX, of course. Intel SGX caught my attention for the first time about 5 years ago, a little while before Intel has officially added information about it to the official Software Developer’s Manual. I’ve written two posts about my thoughts on this (then-upcoming) technology, which were a superposition of both positive and negative feelings. Over the last 2 years or so, together with my team at ITL, we’ve been investigating this fascinating technology a bit closer. Today I’d like to share some introductory information on this interesting project we’ve been working on together with our friends at Golem for several months now.[…]
Reminder to OEMs: publish the hashes of your platform firmware. Hopefully using codehash.db.
In below twitter thread, Joanna asked Dell support for hashes for their firmware. Eventually, Rick Martinez of Dell got involved, so this is a good example of a conversation on this topic by two who understand the issues.
It looks like Dell needs to use HTTPS:
Golem is a global, open sourced, decentralized supercomputer that anyone can access. It’s made up of the combined power of user’s machines, from personal laptops to entire datacenters. Anyone will be able to use Golem to compute (almost) any program you can think of, from rendering to research to running websites, in a completely decentralized & inexpensive way. The Golem Network is a decentralized sharing economy of computing power, where anyone can make money ‘renting’ out their computing power or developing & selling software.
“Bad Valet is the new Evil Maid” –Joanna Rutkowska
“A PoC that the USB port is an attack surface for a Mazda car’s infotainment system and how Mazda hacks are made.”
Re: SCONE, mentioned here: https://firmwaresecurity.com/2017/01/07/secure-linux-containers-with-intel-sgx/
SCONE: Secure Linux Containers with Intel SGX
Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L Stillwell, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter Pietzuch, Christof Fetzer
In multi-tenant environments, Linux containers managed by Docker or Kubernetes have a lower resource footprint, faster startup times, and higher I/O performance compared to virtual machines (VMs) on hypervisors. Yet their weaker isolation guarantees, enforced through software kernel mechanisms, make it easier for attackers to compromise the confidentiality and integrity of application data within containers. We describe SCONE, a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks. The design of SCONE leads to (i) a small trusted computing base (TCB) and (ii) a low performance overhead: SCONE offers a secure C standard library interface that transparently encrypts/decrypts I/O data; to reduce the performance impact of thread synchronization and system calls within SGX enclaves, SCONE supports user-level threading and asynchronous system calls. Our evaluation shows that it protects unmodified applications with SGX, achieving 0.6✓–1.2✓ of native throughput.[…]
Joanna Rutkowska of Invisible Things Lab posted a message to the Secure Desktops list, announcing a new public hash database for software and firmware! lightly-edited announcement below, see the list archive for full announcement:
Introducing a public db for software and firmware hashes:
I’ve recently created this simple repo which is an attempt to somehow addresses a problem of software and firmware “verifiability” (the word is somehow loaded, hence in quotation marks). I imagine that once more and more vendors, such as e.g. Tails or Subgraph, or secure messenger app devs, or various firmware projects (coreboot, Trezor, OpenWRT, etc) agreed to stick to this format, we could expect each of them to submit hashes + signatures with each new release of their software. These hashes would then be subsequently verified and submitted by other witnesses. Each person or organization will be free to host a repo similar to the one above, only with the “proofs” from the select witness they consider somehow trusted or meaningful.
(Now if OEMs and IBVs would only publish their golden image hashes, including after each update….)
“Two years of development later, Cappsule goes open-source! Enjoy!” –September 21st
ORWL has a response to Joanna’s comments on ORWL security:
“Recently, Joanna Rutkowska, the founder of Qubes OS (which we announced as a default OS option), posted on her Invisible Things blog and on Twitter some of her thoughts on ORWL. We offer here our comments and responses to specific points, as well as a more general response. Some of what is described in this update is laid out in our previous update on secure microcontroller (MCU) details.[…]”
ORWL, “The First Open Source, Physically Secure Computer”, just got funded on CrowdSupply!
Joanna Rutkowska wrote a recent post that gives some great background on ORWL’s physical security:
If you have not read about the “Stateless Laptop” proposal, please read it, it covers modern Intel firmware/hardware security issues:
One part in the article talks about how to trust silicon:
The physical protections mentioned above do not, however, resolve the problem of the attackers subverting the laptop hardware at manufacturing or shipment stages. This includes, naturally, a potentially conspiring laptop vendor. In order to address this latter problem we — the industry — need to come up with reliable and simple methods for comparing PCBs with each other. A tool analogical to ‘diff’, only working for PCBs rather than on files. Such a tool, implemented as a software, could e.g. take two (sets of) photos taken by the user of the two boards to compare. The photos might be taken with an ordinary camera, or, in a more sophisticated setup, using X-ray imaging to reveal also the internal layer wiring. This inititive has already been proposed by other researchers recently (e.g. [@appelbaum_technical_action_plan]), so it is not unreasonable to expect some progress in this area in the near future.
So when Make Magazine retweated a recent PCB Xray project, I thought of the above:
Homemade X-Ray Inspector Reveals PCB Secrets
Anyone who has ever tried to reverse engineer a printed circuit board is familiar with the frustration of tracing out the connections by eye and by multimeter. It’s a long process, and if there are multiple layers to the board, you may not even get the full picture. It would be a lot easier if you could just see through the board. On an industrial scale, X-ray inspection machines are used for this, but as you might suspect, they’re not cheap. So, hardware hacker John McMaster built his own.
CCC’s media team is great! Their videos are already online, for day 1. Lots of interesting videos to watch, if you’re not in Germany, including Joanna on the stateless laptop and Trammel on Thunderstrike!
Towards (reasonably) trustworthy x86 laptops
Joanna Rutkowska of Invisible Things Lab (ITL) has proposed the Stateless Laptop, and will be presenting at CCC in a few days (2015/12/27) on the topic.
I can’t begin to create a list of tags this article covers… This article is all about firmware security (and hardware security) for x86 systems, a MUST READ!!
Purism must consider this a holiday gift from ITL: the spec for their next Librem box. Looking forward to this box, built with fully Open Source Hardware designs/parts, hopefully from multiple OEMs next year! 🙂
There are likely other presentations at CCC that’re worth attending, but here are two that you MUST ATTEND, if you’re going to CCC:
Towards (reasonably) trustworthy x86 laptops
Can we build trustworthy client systems on x86 hardware? What are the main challenges? What can we do about them, realistically? Is there anything we can? In the first part we will take a look at the security problems we encounter on modern Intel-based x86 systems, specifically on laptops. In the second part we will discuss how most (all?) of these problems could be addressed, with just minimal hardware modifications realizable by laptop OEMs.
Beyond Anti Evil Maid: Making it easier to avoid low-level compromise, and why you’ll still lose
In 2011, Joanna Rutkowska unveiled an easy-to-use tool for mitigating many attacks on system boot chains by using the TPM – the Anti Evil Maid. Unfortunately the implementation was difficult to incorporate into normal system boot in a secure manner – anybody able to observe a user could recreate the secret. This presentation describes a method to allow systems to prove their identity to the user without making it trivial for attackers to mimic a secure boot and extract secrets from the user, and why the state of modern hardware means this may still not be enough. A correctly implemented Trusted Boot solution makes it possible for systems to prove to other systems that they have booted with the expected boot chain. The Anti Evil Maid technique took advantage of this to encrypt a secret with the TPM in such a way that a system whose firmware or bootloader had been compromised would no longer be able to decrypt that secret. Unfortunately, the use of a static secret makes it easier for an attacker to mimic a good boot – as a result, a sufficiently motivated attacker could circumvent Anti Evil Maid and convince the user that a compromised system was in a good state. This presentation describes the use of shared trust between the system and another device, making it significantly more difficult for an attacker to mimic a trusted boot. It includes a description of the implementation of Trusted Boot support in Free operating systems on modern UEFI systems, how this can be tied into sharing trust between multiple devices and the limitations that may still permit state-level actors to compromise these techniques.
Purism has announced a partnership with Qubes OS, users will be able to order Qubes OS preinstalled on the Librem 13.
Excerpted quotes from press release:
“We are pleased to partner with the Purism team both in offering a certified Qubes OS laptop today, and in the future improving the functionality and security of Purism laptops to ensure that users can have the best of freedom, security and privacy in one convenient package,” said Joanna Rutkowska, well-known security researcher and founder of the Qubes OS project.
“We are ecstatic about the partnership between Purism and Qubes so we can bring together our goals of privacy, security and freedom in hardware with the best approach in software security. This union represents the ideal approach to protecting users by default, without sacrificing convenience or usability,” said Todd Weaver, CEO of Purism. “Qubes OS is a natural fit with the Purism Librem laptops in both functionality and ideology.”
Full press release:
I was originally wondering why not use Qubes instead of PureOS in the first place, so I’m happy with their use of Qubes for OS solution.
I’m unclear about status of PureOS, is it mothballed or is it another OS option for Librem? Given use of Qubes, what does this say about future hardware architecture choices by Purism? AFAICT, Qubes is an Intel/AMD-centric OS, will PureOS still be used on ARM-based tablets/smartphones? Will Qubes have any ARM port?
Wow, Joanna of ITL says “IMHO this is the worst bug affecting Xen, ever.”
Excerpt from Qubes Security Bulletin #22:
Critical Xen bug in PV memory virtualization code (XSA 148)
The Xen Security Team has announced a critical security bug (XSA 148) in the hypervisor code handling memory virtualization for the PV VMs :
| The code to validate level 2 page table entries is bypassed when
| certain conditions are satisfied. This means that a PV guest can
| create writeable mappings using super page mappings.
| Such writeable mappings can violate Xen intended invariants for pages
| which Xen is supposed to keep read-only.
The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly.