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[…]



Signing boot images for Android Verified Boot

Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]


More Info:



Exploiting Samsung’s Secure Bootloader (S-Boot) for Android

Exploiting Android S-Boot: Getting Arbitrary Code Exec in the Samsung Bootloader (1/2)
Nitay Artenstein (@nitayart) and Gilad Goldman (@gnull00)

Samsung’s Secure Bootloader (S-Boot) for Android lies at the heart of Samsung’s chain of trust concept. An attacker who compromises S-Boot could potentially load an untrusted kernel and system image, therefore bypassing most of the phone’s security mechanisms. This is a well-known attack vector: It’s often used by the Android rooting and modding community, but our guess is that it’s way more popular with law enforcement and government agencies. All the more interesting, then, that S-Boot on contains several memory corruption bugs, one of which could be used to reach full code execution within the bootloader. We can currently confirm the existence of the vulnerability only on Exynos chipsets. It seems universal to approximately 90% of the Samsung Exynos ROMs running on S5, S6 and S7. The very newest ROMs for S7 (February 2017) appear to include a fix for this bug, but we’ll confirm this in a few days. There’s a lot of ground to cover, so we’ll break up this write-up into two posts. In this post we’ll focus on some S-Boot internals, then explore the bootloader’s attack surface and get basic debugging capabilities. We’ll end the post with the discovery of an especially interesting attack surface. In the next post we’ll disclose the actual vulnerability and how we exploited it to get code execution in S-Boot. We won’t go into much detail on the basics of reversing S-Boot, such as how to load it into IDA or find the base address. Fernand Lone Sang (@_kamino_) is about to publish a great article exactly about that and I’ll put a link for it here when it’s out. If you need any help beyond that, just DM me and I’d be glad to give you a hand if I can.[…]


Android Things

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





OnePlus bootloader vulnerabilities


Owning a Locked OnePlus 3/3T: Bootloader Vulnerabilities
Feb 08, 2017 • Roee Hay
In this blog post I disclose two vulnerabilities in the OnePlus 3/3T bootloader. The first one, CVE-2017-5626, is a critical severity vulnerability affecting OxygenOS 3.2-4.0.1 (4.0.2 is patched). The vulnerability allows for a physical adversary (or one with ADB/fastboot access) to bypass the bootloader’s lock state, even when Allow OEM Unlocking is disabled, without user confirmation and without triggering a factory reset. This vulnerability allows for kernel code execution (albeit with a 5 seconds warning upon boot). The second vulnerability, CVE-2017-5624, affecting all versions of OxygenOS to date (Feb 10 UPDATE: OxygenOS 4.0.3, released Feb 09, seems to be patched), allows the attacker to disable dm-verity. The combination of the vulnerabilities enables a powerful attack – persistent highly privileged code execution without any warning to the user and with access to the original user’s data (after the victim enters his credentials). Both issues were responsibly disclosed to and acknowledged by OnePlus Security. The first vulnerability, CVE-2017-5626, was reported on January 23rd. It was also found independently by a OnePlus engineer. CVE-2017-5624, reported on January 16th, should be fixed in a future OxygenOS release – the reason for its today’s public disclosure is because someone already published it on January 24th. Disclaimer: I tested the vulnerabilities on OnePlus 3 only, but OnePlus 3T contains the vulnerable code too.[…[