Android Oreo’s rollback protection required on phones launching with Android Pie

Android Pie (Android 9) just went live today for the Google Pixel, Google Pixel 2, and even the Essential Phone. We’re learning as much as we can about the release from interviews (the Google Pixel 3 will only have gesture navigation!), the AOSP code drop, and lastly the Compatibility Definition Document (CDD). We posted about a new feature for “heavyweight” apps earlier today, but now we’ve found that Google has changed their wording on a feature introduced in Android Oreo: rollback protection. The feature is made possible by Android Verified Boot 2.0 (also known simply as Verified Boot), however, OEMs were not required to implement AVB 2.0 in the Oreo release. Now, Google is mandating that all devices launching with Android Pie support Verified Boot, and by extension, rollback protection.

Rollback Protection in Android Oreo

The gist of the feature is that it’ll prevent your phone from booting if it detects that the device was downgraded to an earlier, now unapproved version of software that has been deemed insecure because of a security vulnerability. A slightly more technical explanation is that the VBMeta data structure, which holds the hash for the boot partition and hashtree metadatas for system and vendor partitions, uses a rollback index to reject images that have an older rollback index.

Rollback Protection in Android Verified Boot. Source: Google.

This feature is present on devices like the Google Pixel 2, Razer Phone, and OnePlus 6 but is not present on many other devices like the Samsung Galaxy S9 (though Samsung does offer their own form of rollback protection in Knox.) Now, Google is making the feature mandatory for any device launching with Android Pie.

Verified Boot in Android Pie

According to the updated wording in the “Device Integrity” section in the Compatibility Definition Document, devices that launch with Android 9 must support Verified Boot.

9.10. Device Integrity

The following requirements ensures there is transparancy to the status of the device integrity. Device implementations:

• [C-0-1] MUST correctly report through the System API method PersistentDataBlockManager.getFlashLockState() whether their bootloader state permits flashing of the system image. The FLASH_LOCK_UNKNOWN state is reserved for device implementations upgrading from an earlier version of Android where this new system API method did not exist.
• [C-0-2] MUST support Verified Boot for device integrity.

If device implementations are already launched without supporting Verified Boot on an earlier version of Android and can not add support for this feature with a system software update, they MAY be exempted from the requirement.

…

• [C-1-10] MUST implement rollback protection for partitions used by Android (e.g. boot, system partitions) and use tamper-evident storage for storing the metadata used for determining the minimum allowable OS version.
• SHOULD implement rollback protection for any component with persistent firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for storing the metadata used for determining the minimum allowable version.

As you can see in the last two set of bullet points, there is one caveat to note. Rollback protection is required for partitions used by Android (boot, system, vendor, etc.) but not for partitions with persistent firmware (modem, camera, etc.). The former set of partitions is where most of the security vulnerabilities are discovered and patched so it’s nice to see that protecting these partitions is mandated. However, there have been exploits that target partitions with persistent firmware as well so we’re unsure why Google isn’t mandating rollback protection on them.

XDA Senior Member npjohnson, a member of the LineageOS team, speculates that requiring rollback protection on partitions with persistent firmware would require Secondary Bootloader (SBL) and eXtensible Bootloader (XBL) tie-ins since these partitions are mounted earlier in the boot process. It would be costly for smaller OEMs to implement customized XBLs to match the customized modems and other persistent partitions, so perhaps Google isn’t making this a requirement to make it easier for device makers to meet the latest requirements in the CDD.

How to check if your phone supports AVB 2.0

There are two ADB shell commands you can use to check if your phone supports AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

OR

adb shell
getprop | grep "avb"

If the output of the first command is “android.software.verified_boot” then AVB 2.0 is supported. If the output of the second command shows “[ro.boot.avb_version]” and “[ro.boot.vbmeta.avb_version]” and lists a version number for each, then it’s supported.

Verified Boot and Custom Development

Android Verified Boot doesn’t really affect most custom ROM users although it does add an extra layer of security you have to work around in some instances. For instance, flashing a Generic System Image requires disabling AVB. Modifying certain partitions like vendor on the OnePlus 6 requires disabling AVB as well, as I recently learned. According to npjohnson, properly implemented AVB 2.0 makes it possible for custom boot images to work with a locked bootloader. We’ll see how the inclusion of AVB 2.0 on devices shipping with Android Pie affects the landscape, but we hope it doesn’t result in situations like the recent bricking scare in the Xiaomi Redmi Note 5 Pro community. Mandatory AVB 2.0 is just another way for Google to improve Android platform security, but the biggest change, in our view, is the re-working of OEM agreements to mandate regular security patches.

from xda-developers https://ift.tt/2MsTpek
via IFTTT