Uncategorized

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection
By Roee Hay (@roeehay)
In the May 2017 Android Security Bulletin, Google released a patch to a critical and unique vulnerability CVE-2016-10277 in the Nexus 6 bootloader we had found and responsibly disclosed. By exploiting the vulnerability, a physical adversary or one with authorized-ADB/fastboot USB access to the (bootloader-locked) device (such as PC malware awaiting for an ADB-authorized developer’s device to be hooked via USB) could break the Secure/Verified Boot mechanism, allowing him to gain unrestricted root privileges, and completely own the user space (which may also lead much more), by loading a tampered or malicious initramfs image. Moreover, exploitation does not lead to a factory reset hence user data remains intact (and still encrypted). It should be noted that we do not demonstrate an untethered attack. During this research we also uncovered a 18-year-old Linux Kernel bug (not affecting Nexus 6 and probably does not affect any Android device): CVE-2017-1000363[…]

https://alephsecurity.com/2017/05/23/nexus6-initroot/

Standard
Uncategorized

Google Fuchsia

https://fuchsia.googlesource.com/
https://fuchsia.googlesource.com/magenta/
https://github.com/fuchsia-mirror

http://spectrum.ieee.org/tech-talk/computing/software/a-modern-os-from-google
http://www.osdrawer.net/fuchsia-googles-new-operating-system/
https://en.wikipedia.org/wiki/Google_Fuchsia

https://firmwaresecurity.com/2016/08/15/uefi-bootloader-for-google-fuchsia/

 

Standard
Uncategorized

Google: exploiting Broadcom’s Wi-Fi

Google ProjectZero has an excellent blog post on Broadcom WiFi firmware.

[…]In this two-part blog series, we’ll explore the exposed attack surface introduced by Broadcom’s Wi-Fi SoC on mobile devices. Specifically, we’ll focus our attention on devices running Android, although a vast amount of this research applies to other systems including the same Wi-Fi SoCs. The first blog post will focus on exploring the Wi-Fi SoC itself; we’ll discover and exploit vulnerabilities which will allow us to remotely gain code execution on the chip. In the second blog post, we’ll further elevate our privileges from the SoC into the the operating system’s kernel. Chaining the two together, we’ll demonstrate full device takeover by Wi-Fi proximity alone, requiring no user interaction. We’ll focus on Broadcom’s Wi-Fi SoCs since they are the most common Wi-Fi chipset used on mobile devices. A partial list of devices which make use of this platform includes the Nexus 5, 6 and 6P, most Samsung flagship devices, and all iPhones since the iPhone 4. For the purpose of this blog post, we’ll demonstrate a Wi-Fi remote code execution exploit on a fully updated (at the time, now fixed) Nexus 6P, running Android 7.1.1 version NUF26K.  All the vulnerabilities in the post have been disclosed to Broadcom. Broadcom has been incredibly responsive and helpful, both in fixing the vulnerabilities and making the fixes available to affected vendors. For a complete timeline, see the bug tracker entries. They’ve also been very open to discussions relating to the security of the Wi-Fi SoC. I would like to thank Thomas Dullien (@halvarflake) for helping boot up the research, for the productive brainstorming, and for helping search the literature for any relevant clues. I’d also like to thank my colleagues in the London office for helping make sense of the exploitation constraints, and for listening to my ramblings. […]

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

https://bugs.chromium.org/p/project-zero/issues/detail?id=1046#c2

http://www.wi-fi.org/product-finder-results?sort_by=default&sort_order=desc&categories=1,2,4,6,7,5,9,3&certifications=38

https://news.ycombinator.com/item?id=14034092

https://arstechnica.com/security/2017/04/wide-range-of-android-phones-vulnerable-to-device-hijacks-over-wi-fi/

I do not look forward to the day that most Redfish implementations are WiFi-based. 😦

Standard
Uncategorized

U-Root: firmware solution written in Go

From 2015, something I missed because I didn’t know Go then. ;-(

U-root: A Go-based, Firmware Embeddable Root File System with On-demand Compilation
Ronald G. Minnich, Google; Andrey Mirtchovski, Cisco

U-root is an embeddable root file system intended to be placed in a FLASH device as part of the firmware image, along with a Linux kernel. The program source code is installed in the root file system contained in the firmware FLASH part and compiled on demand. All the u-root utilities, roughly corresponding to standard Unix utilities, are written in Go, a modern, type-safe language with garbage collection and language-level support for concurrency and inter-process communication. Unlike most embedded root file systems, which consist largely of binaries, U-root has only five: an init program and 4 Go compiler binaries. When a program is first run, it and any not-yet-built packages it uses are compiled to a RAM-based file system. The first invocation of a program takes a fraction of a second, as it is compiled. Packages are only compiled once, so the slowest build is always the first one, on boot, which takes about 3 seconds. Subsequent invocations are very fast, usually a millisecond or so. U-root blurs the line between script-based distros such as Perl Linux and binary-based distros such as BusyBox; it has the flexibility of Perl Linux and the performance of BusyBox. Scripts and builtins are written in Go, not a shell scripting language. U-root is a new way to package and distribute file systems for embedded systems, and the use of Go promises a dramatic improvement in their security.

Video and audio on first URL.

https://www.usenix.org/conference/atc15/technical-session/presentation/minnich

https://github.com/u-root/u-root

http://u-root.tk/

Standard
Uncategorized

Android Things

Supported hardware: Intel® Edison, Intel® Joule, NXP Pico i.MX6UL, Raspberry Pi

https://github.com/androidthings
https://developer.android.com/things/hardware/index.html
https://developer.android.com/things/index.html
https://developer.android.com/things/preview/index.html
https://developer.android.com/things/hardware/developer-kits.html
https://android-developers.googleblog.com/2017/02/android-things-developer-preview-2.html

 

 

Standard
Uncategorized

Google on fuzzing PCIe

Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer

Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]

https://cloudplatform.googleblog.com/2017/02/fuzzing-PCI-Express-security-in-plaintext.html

Standard
Uncategorized

Matthew Garrett leaves CoreOS, joins Google

Matthew Garrett is leaving CoreOS and has gone to Google!

https://coreos.com/blog/working-on-container-linux.html

 

Standard