Only slightly overdue, this post is about our recent IEEE Security and Privacy 2015 paper, CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. We’ve previously written about how our CHERI processor blends a conventional RISC ISA and processor pipeline design with a capability-system model to provide fine-grained memory protection within virtual address spaces (ISCA 2014, ASPLOS 2015). In our this new paper, we explore how CHERI’s capability-system features can be used to implement fine-grained and scalable application compartmentalisation: many (many) sandboxes within a single UNIX process — a far more efficient and programmer-friendly target for secure software than current architectures.
Today we unveil two papers describing serious and widespread vulnerabilities in Android mobile phones. The first presents a Security Analysis of Factory Resets. Now that hundreds of millions of people buy and sell smartphones secondhand and use them for everything from banking to dating, it’s important to able to sanitize your phone. You need to clean it when you buy it, so you don’t get caught by malware; and even more when you sell it, so you don’t give away your bank credentials or other personal information. So does the factory reset function actually work? We bought a couple of dozen second-hand Android phones and tested them to find out.
The news is not at all good. We were able to retrieve the Google master cookie from the great majority of phones, which means that we could have logged on to the previous owner’s gmail account. The reasons for failure are complex; new phones are generally better than old ones, and Google’s own brand phones are better than the OEM offerings. However the vendors need to do a fair bit of work, and users need to take a fair amount of care.
Attacks on a sold phone that could not be properly sanitized are one example of what we call a “user-not-present” attack. Another is when your phone is stolen. Many security software vendors offer a facility to lock or wipe your phone remotely when this happens, and it’s a standard feature with mobile antivirus products. Do these ‘solutions’ work?
You guessed it. Antivirus software that relies on a faulty factory reset can only go so far, and there’s only so much you can do with a user process. The AV vendors have struggled with a number of design tradeoffs, but the results are not that impressive. See Security Analysis of Consumer-Grade Anti-Theft Solutions Provided by Android Mobile Anti-Virus Apps for the gory details. These failings mean that staff at firms which handle lots of second-hand phones (whether lost, stolen, sold or given to charity) could launch some truly industrial-scale attacks. These papers appear today at the Mobile Security Technology workshop at IEEE Security and Privacy.
Kirk McKusick, George Neville-Neil, and I are pleased to announce that The Design and Implementation of the FreeBSD Operating System, Second Edition is now available from Pearson Education (Amazon link for non-US folk). Light Blue Touchpaper readers might be particularly interested in the new chapter on FreeBSD’s kernel security features including:
- Process Credentials
- Users and Groups
- Privilege Model
- Interprocess Access Control
- Discretionary Access Control
- Capsicum Capability Model
- Mandatory Access-Control Framework
- Security Event Auditing
- Cryptographic Services
- GELI Full-Disk Encryption
There is detailed coverage of the FreeBSD TCB, POSIX.1e and NFSv4 ACLs, OS sandboxing features, the Mandatory Access Control Framework used not just in FreeBSD but also Junos/Mac OS X/iOS, the FreeBSD kernel’s Yarrow-based pseudo-random number generator, and both confidentiality and integrity cryptographic protection for filesystems, and the kernel’s IPsec implementation. Other new content in this edition of the book includes ZFS, paravirtualised device drivers, DTrace, NFSv4, network-stack virtualisation, and much more.
We will be using this book as one of the core texts for our new masters-level operating-system course at Cambridge, L41, in spring 2015.
Last week, Jonathan Woodruff presented our joint paper on the CHERI memory model, The CHERI capability model: Revisiting RISC in an age of risk, at the 2014 International Symposium on Computer Architecture (ISCA) in Minneapolis (video, slides). This is our first full paper on Capability Hardware Enhanced RISC Instructions (CHERI), collaborative work between Simon Moore’s and my team composed of members of the Security, Computer Architecture, and Systems Research Groups at the University of Cambridge Computer Laboratory, Peter G. Neumann’s group at the Computer Science Laboratory at SRI International, and Ben Laurie at Google.
CHERI is an instruction-set extension, prototyped via an FPGA-based soft processor core named BERI, that integrates a capability-system model with a conventional memory-management unit (MMU)-based pipeline. Unlike conventional OS-facing MMU-based protection, the CHERI protection and security models are aimed at compilers and applications. CHERI provides efficient, robust, compiler-driven, hardware-supported, and fine-grained memory protection and software compartmentalisation (sandboxing) within, rather than between, addresses spaces. We run a version of FreeBSD that has been adapted to support the hardware capability model (CheriBSD) compiled with a CHERI-aware Clang/LLVM that supports C pointer integrity, bounds checking, and capability-based protection and delegation. CheriBSD also supports a higher-level hardware-software security model permitting sandboxing of application components within an address space based on capabilities and a Call/Return mechanism supporting mutual distrust.
The approach draws inspiration from Capsicum, our OS-facing hybrid capability-system model now shipping in FreeBSD and available as a patch for Linux courtesy Google. We found that capability-system approaches matched extremely well with least-privilege oriented software compartmentalisation, in which programs are broken up into sandboxed components to mitigate the effects of exploited vulnerabilities. CHERI similarly merges research capability-system ideas with a conventional RISC processor design, making accessible the security and robustness benefits of the former, while retaining software compatibility with the latter. In the paper, we contrast our approach with a number of others including Intel’s forthcoming Memory Protection eXtensions (MPX), but in particular pursue a RISC-oriented design instantiated against the 64-bit MIPS ISA, but the ideas should be portable to other RISC ISAs such as ARMv8 and RISC-V.
Our hardware prototype is implemented in Bluespec System Verilog, a high-level hardware description language (HDL) that makes it easier to perform design-space exploration. To facilitate both reproducibility for this work, and also future hardware-software research, we’ve open sourced the underlying Bluespec Extensible RISC Implementation (BERI), our CHERI extensions, and a complete software stack: operating system, compiler, and so on. In fact, support for the underlying 64-bit RISC platform, which implements a version of the 64-bit MIPS ISA, was upstreamed to FreeBSD 10.0, which shipped earlier this year. Our capability-enhanced versions of FreeBSD (CheriBSD) and Clang/LLVM are distributed via GitHub.
You can learn more about CHERI, BERI, and our larger clean-slate hardware-software agenda on the CTSRD Project Website. There, you will find copies of our prior workshop papers, full Bluespec source code for the FPGA processor design, hardware build instructions for our FPGA-based tablet, downloadable CheriBSD images, software source code, and also our recent technical report, Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture, and Jon Woodruff’s PhD dissertation on CHERI.
Jonathan Woodruff, Robert N. M. Watson, David Chisnall, Simon W. Moore, Jonathan Anderson, Brooks Davis, Ben Laurie, Peter G. Neumann, Robert Norton, and Michael Roe. The CHERI capability model: Revisiting RISC in an age of risk, Proceedings of the 41st International Symposium on Computer Architecture (ISCA 2014), Minneapolis, MN, USA, June 14–16, 2014.
I’m at the IEEE Symposium on Security and Privacy, known in the trade as “Oakland” even though it’s now moved to San Jose. It’s probably the leading event every year in information security. I will try to liveblog it in followups to this post.
We are pleased to announce a job ad for two new research assistants or post-doctoral research associates working on our CTSRD Project, whose target research areas include OS, compiler, and CPU security. This is a joint project between the University of Cambridge’s Security, NetOS, and Computer Architecture research groups, as well as the Computer Science Laboratory at SRI International.
Research Assistants and Associates in OS, Compiler and CPU Security
Fixed-term: The funds for this post are available for 18 months in the first instance.
We are seeking multiple Research Assistants and Post-Doctoral Research Associates to join the CTSRD Project, which is investigating fundamental improvements to CPU-architecture, operating-system (OS), program-analysis, and programming-language structure in support of computer security. The CTSRD Project is a collaboration between the University of Cambridge and SRI International, and part of the DARPA CRASH research programme on clean-slate computer system design for security. More information may be found at:
This position will be an integral part of an international team of researchers spanning multiple institutions in academia and industry. Successful candidates will contribute to the larger research effort by performing system-software, compiler, and hardware implementation and experimentation, developing and evaluating novel hypotheses about refinements to the vertical hardware-software stack. Possible areas of responsibility include: modifying OS kernels (e.g., FreeBSD), adapting compiler suites (e.g., Clang/LLVM); extending an open-source Bluespec-based research-processor design (CHERI); supporting an early-adopter user community for open-source hardware and software; and improving the quality and performance of hardware-software prototypes. The successful candidate must be willing to travel in the UK and abroad engaging with downstream user communities.
Continue reading Research Assistants and Associates in OS, Compiler and CPU Security
It’s been a busy year for Capsicum, practical capabilities for UNIX, so a year-end update seemed in order:
The FreeBSD Foundation and Google jointly funded a Capsicum Integration Project that took place throughout 2013 — described by Foundation project technical director Ed Maste in a recent blog article. Pawel Jakub Dawidek refined several Capsicum APIs, improving support for ioctls and increasing the number of supported capability rights for FreeBSD 10. He also developed Casper, a helper daemon that provides services (such as DNS, access to random numbers) to sandboxes — and can, itself, sandbox services. Casper is now in the FreeBSD 11.x development branch, enabled by default, and should appear in FreeBSD 10.1. The Google Open Source Program Office (OSPO) blog also carried a September 2013 article on their support for open-source security, featuring Capsicum.
Capsicum is enabled by default in the forthcoming FreeBSD 10.0 release — capability mode, capabilities, and process descriptors are available in the out-of-the-box GENERIC kernel. A number of system services use Capsicum to sandbox themselves — such as the DHCP client, high-availability storage daemon, audit log distribution daemon, but also command-line tools like kdump and tcpdump that handle risky data. Even more will appear in FreeBSD 10.1 next year, now that Casper is available.
David Drysdale at Google announced Capsicum for Linux, an adaptation of Linux to provide Capsicum’s capability mode and capabilities, in November 2013. David and Ben Laurie visited us in Cambridge multiple times this year to discuss the design and implementation, review newer Capsicum APIs, and talk about future directions. They hope to upstream this work to the Linux community. Joris Giovannangeli also announced an adaptation of Capsicum to DragonFlyBSD in October 2013.
Over the summer, Mariusz Zaborski and Daniel Peryolon were funded by Google Summer of Code to work on a variety of new Capsicum features and services, adapting core UNIX components and third-party applications to support sandboxing. For example, Mariusz looked at sandboxing BSD grep: if a vulnerability arises in grep’s regular-expression matching, why should processing a file of malicious origin yield full rights to your UNIX account?
In May 2013, our colleagues at the University of Wisconsin, Madison, led by Bill Harris, published a paper at the IEEE Symposium on Security and Privacy (“Oakland”) on “Declarative, Temporal, and Practical Programming with Capabilities” — how to model program behaviour, and automatically transform some classes of applications to use Capsicum sandboxing. We were very pleased to lend a hand with this work, and feel the art of programming for compartmentalisation is a key research challenge. We also collaborated with folk at SRI and Google on a a workshop paper developing our ideas about application compartmentalisation, which appeared at the Security Protocols Workshop here in Cambridge in March 2013.
Google and the FreeBSD Foundation are committed to further work on Capsicum and its integration with applications, and research continues on how to apply Capsicum at several institutions including here at Cambridge. We hope to kick off a new batch of application adaptation in coming months — as well as integration with features such as DNSSEC. However, we also need your help in adapting applications to use Capsicum on systems that support it!
Today we’re presenting a new side-channel attack in PIN Skimmer: Inferring PINs Through The Camera and Microphone at SPSM 2013. We found that software on your smartphone can work out what PIN you’re entering by watching your face through the camera and listening for the clicks as you type. Previous researchers had shown how to work out PINs using the gyro and accelerometer; we found that the camera works about as well. We watch how your face appears to move as you jiggle your phone by typing.
There are implications for the design of electronic wallets using mechanisms such as Trustzone which enable some apps to run in a more secure sandbox. Such systems try to prevent sensitive data such as bank credentials being stolen by malware. Our work shows it’s not enough for your electronic wallet software to grab hold of the screen, the accelerometers and the gyro; you’d better lock down the video camera, and the still camera too while you’re at it. (Our attack can use the still camera in burst mode.)
We suggest ways in which mobile phone operating systems might mitigate the risks. Meanwhile, if you’re developing payment apps, you’d better be aware that these risks exist.
I was pleased to contribute to a recent blog article by Ben Laurie, a frequent collaborator with the Cambridge security group, on the Google Open Source Programs Office blog. We describe open-source security work OSPO has sponsored over the last couple of years, including our joint work on Capsicum, and its followup projects funded jointly by Google and the FreeBSD Foundation. He also talks about Google support for Certificate Transparency, OpenSSL, Tor, and Libpurple — projects focussed not just on communications security, but also communications privacy on the Internet.
Over the last decade or so, it has become increasingly (and painfully) apparent that ACLs and MAC, which were originally designed to protect expensive mainframes from their users, and the users from each other, are failing to secure modern cheap machines with single users who need protecting from the software they run.
Instead, we need fine-grained access control and strong sandboxing.
Continue reading Google funding of open-source security projects
The CTSRD Project is advertising two posts in processor, operating system, and compiler security. The first is a research assistant position, suitable for candidates who may not have a research background, and the second is a post-doctoral research associate position suitable for candidates who have completed (or will shortly complete) a PhD in computer science or a related field.
The CTSRD Project is investigating fundamental improvements to CPU architecture, operating system (OS) design, and programming language structure in support of computer security. The project is a collaboration between the University of Cambridge and SRI International, and part of the DARPA CRASH research programme on clean-slate computer system design.
These positions will be integral parts of an international team of researchers spanning multiple institutions across academia and industry. Successful candidate will provide support for the larger research effort by contributing to low-level hardware and system-software implementation and experimentation. Responsibilities will include extending Bluespec-based CHERI processor designs, modifying operating system kernels and compiler suites, administering test and development systems, as well as performing performance measurements. The position will also support and engage with early adopter communities for our open-source research platform in the UK and abroad.
Candidates should have strong experience with at least one of Bluespec HDL, OS kernel development (FreeBSD preferred), or compiler internals (LLVM preferred); strong experience with the C programming language and use of revision control in large, collaborative projects is essential. Some experience with computer security and formal methods is also recommended.
Both posts are intended to start on 8 July 2013; applications must be received by 9 May 2013.