by Sami Tolvanen, Staff Software Engineer, Android Security
Android’s security model is enforced by the Linux kernel, which makes it a tempting target for attackers. We have put a lot of effort into hardening the kernel in previous Android releases and in Android 9, we continued this work by focusing on compiler-based security mitigations against code reuse attacks. Google’s Pixel 3 will be the first Android device to ship with LLVM’s forward-edge Control Flow Integrity (CFI) enforcement in the kernel, and we have made CFI support available in Android kernel versions 4.9 and 4.14. This post describes how kernel CFI works and provides solutions to the most common issues developers might run into when enabling the feature.[…]
Everything we know about Campfire, Google’s secretive project to get Windows 10 running on Chromebooks.[…]
This story gives some background on Google’s Fuchsia platform.
Project ‘Fuchsia’: Google is Quietly Working on a Successor to Android
By Mark Bergen
and Mark Gurman
July 19, 2018, 3:00 AM PDT Updated on July 19, 2018, 8:31 AM PDT
This is a 3-year-old tool, I just noticed. it. 😦
Google has created rowhammer-test to help with Rowhammer detection. Currently it works on Linux and Mac on Intel systems.
There’s also a mailing list for related discussions.
[…]To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.[…]
In light of Spectre/Meltdown, we needed to re-think our threat model and defenses for Chrome renderer processes. Spectre is a new class of hardware side-channel attack that affects (among many other targets) web browsers. This document describes the impact of these side-channel attacks and our approach to mitigating them. The upshot of the latest developments is that the folks working on this from the V8 side are increasingly convinced that there is no viable alternative to Site Isolation as a systematic mitigation to SSCAs [speculative side-channel attacks]. In this new mental model, we have to assume that user code can reliably gain access to all data within a renderer process through speculation. This means that we definitely need some sort of ‘privileged/PII data isolation’ guarantees as well, for example ensuring that password and credit card info are not speculatively loaded into a renderer process without user consent. […] In fact, any software that both (a) runs (native or interpreted) code from more than one source; and (b) attempts to create a security boundary inside a single address space, is potentially affected. For example, software that processes document formats with scripting capabilities, and which loads multiple documents from different sources into the same process, may need to take defense measures similar to those described here.[…]
Alex Deymo notes that the Android project has more documentation on their boot process, and posted about it on the U-Boot mailing list:
“Just an FYI, earlier this month the team spent some time polishing and publishing in source.android.com documentation about the flows the bootloader goes through in Android, specially true for stock Android like in Pixels phones or other devices based of recent AOSP versions. This documentation includes the interaction between userspace and the bootloader such as the properties userspace expects when booting A/B devices, the whole A/B flow, the bootloader message in the misc partition (BCB), how they interact with the “recovery mode” in Android and much more.
What is GLitch?
GLitch is one part of our series of Rowhammer attacks. We started by breaking the EDGE browser and the cloud. Then we moved towards Android devices showing how to root them with bit flips. This time we wanted to show that also mobile phones can be attacked remotely via the browser.
Meet GLitch: the first instance of a remote Rowhammer exploit on ARM Android devices. This makes it possible for an attacker who controls a malicious website to get remote code execution on a smartphone without relying on any software bug.
You want to know what makes this attack even cooler? It is carried out by the GPU. This is the first GPU-accelerated Rowhammer attack.[…]
[…]Today we’re excited to announce Asylo (Greek for “safe place”), a new open-source framework that makes it easier to protect the confidentiality and integrity of applications and data in a confidential computing environment. Asylo is an open-source framework and SDK for developing applications that run in trusted execution environments (TEEs). TEEs help defend against attacks targeting underlying layers of the stack, including the operating system, hypervisor, drivers, and firmware, by providing specialized execution environments known as “enclaves”. TEEs can also help mitigate the risk of being compromised by a malicious insider or an unauthorized third-party. Asylo includes features and services for encrypting sensitive communications and verifying the integrity of code running in enclaves, which help protect data and applications.[…]
[…]Drewry and Liu focused on four key features for the Chromebook that have been available ever since the first iteration in 2010:
power washing and
These provided security features that made it much harder for malware to pass through, while providing a quick fix-it button if it ever did. “That’s the fundamental difference between how Chrome OS works and how any other computer at the time worked,” Liu said.[…]
[…]Here’s the problem: there’s no way to know a priori which instructions your CPU supports. Identifying the CPU manufacturer isn’t sufficient. For instance, Intel’s Haswell architecture supports the AVX2 instruction set, while Sandy Bridge doesn’t. Some developers resort to desperate measures like reading /proc/cpuinfo to identify the CPU and then consulting hardcoded mappings of CPU IDs to instructions. Enter cpu_features, a small, fast, and simple open source library to report CPU features at runtime. Written in C89 for maximum portability, it allocates no memory and is suitable for implementing fundamental functions and running in sandboxed environments. The library currently supports x86, ARM/AArch64, and MIPS processors, and we’ll be adding to it as the need arises. We also welcome contributions from others interested in making programs “write once, run fast everywhere.”
By Guillaume Chatelet, Google Compiler Research Team
Golem has a story about the recent Google presentation at OSSEU2017:
From Google Translation of German text:
Google wants servers without Intel ME and UEFI
by Sebastian Grüner
According to the motto “Are you afraid?” a team of Google’s coreboot developers is working with colleagues to make Intel’s ME and the proprietary UEFI harmless in servers. And probably with success.[…]
Maybe I missed it, but I didn’t see the video of this presentation archived.