For a long time in its early history, Android had a reputation for being less secure than iOS because of Apple’s “walled garden” approach to applications. Whether or not that past reputation is deserved isn’t something that we’re going to dive into, but it’s clear that Google has made great strides in securing Android against vulnerabilities. Not only is the company providing new security features in the latest version of Android, Android P, but they are also providing “enterprise-grade security” in their latest devices thanks to a hardware security module in the Google Pixel 2/2 XL. Keeping a device secure also requires continuous updates to patch all of the latest threats, too, which is why Google has monthly security bulletins for all device makers and vendors to incorporate patches against all known active and potential vulnerabilities. Now, it appears that the company may be making changes to the Android Security Patch system by providing a way to distinguish between the Android framework patch level and the vendor patch level along with the bootloader, kernel, etc. to either split the security patch levels so OEMs can provide pure framework updates or better identify to the user what patch level they are running.
Monthly Android Security Patches – A Primer
We all know security patches are important, especially after a string of high-profile vulnerabilities were made public in the second half of last year. The BlueBorne vulnerability attacked the Bluetooth protocol and was patched in the September 2017 monthly patches, KRACK targets a weakness in Wi-Fi WPA2 and was patched in December 2017, and the Spectre/Meltdown vulnerabilities were mostly fixed with the January 2018 patches. Patching vulnerabilities such as these typically require cooperation with a hardware vendor (such as Broadcom and Qualcomm) because the vulnerability concerns a hardware component such as the Wi-Fi or Bluetooth chip or the CPU. On the other hand, there are issues in the Android operating system such as this toast message overlay attack that only require an update to the Android Framework in order to fix.
Whenever Google rolls out a monthly security patch, device makers are required to fix ALL of the vulnerabilities outlined in that month’s security bulletin if they want to say that their device is secure up to that monthly patch level. Each month, there are two security patch levels that a device can meet: the patch level at the 1st of the month or the 5th of the month. If a device says it is running a patch level from the 1st of the month (eg. April 1st rather than April 5th) then that means the build contains all framework AND vendor patches from the last month’s release plus all framework patches from the newest security bulletin. On the other hand, if a device says it is running a patch level from the 5th of the month (April 5th, for example), then that means it contains all framework and vendor patches from last month and this month’s bulletin. Here’s a table that exemplifies the basic difference between the monthly patch levels:
| Monthly Security Patch Level | April 1st | April 5th |
|---|---|---|
| Contains April Framework Patches | Yes | Yes |
| Contains April Vendor Patches | No | Yes |
| Contains March Framework Patches | Yes | Yes |
| Contains March Vendor Patches | Yes | Yes |
You’re probably familiar with how dismal the security patch situation is in the Android ecosystem. The chart below shows that Google and Essential provide the fastest monthly security patch updates while other companies fall behind. It can take months for an OEM to bring the latest patches to a device, such as how the OnePlus 5 and OnePlus 5T recently received the April security patch when they were previously on December’s patch.
Android Security Patch status as of February 2018. Source: @SecX13
The problem with providing Android Security Patch updates isn’t necessarily that OEMs are lazy, as sometimes it can be out of their control. As we mentioned previously, monthly security patch updates often require the cooperation of a hardware vendor, which can cause delays if the vendor is unable to keep up with the monthly security patch bulletins. To combat this, it appears that Google may begin separating the Android Framework security patch level from the vendor patch level (and possibly the bootloader and kernel level) so that in the future, OEMs may be able to provide purely Android framework security updates.
Faster Android Security Patch updates for Framework Vulnerabilities?
A new commit has appeared in the Android Open Source Project (AOSP) gerrit that hints at a “vendor security patch prop” which would be defined in the Android.mk files whenever a new build for a device is being created. This property will be called “ro.vendor.build.security_patch” and will be analogous to “ro.build.version.security_patch” which currently exists on all Android devices to specify the monthly Android Security Patch level.
This new property will instead tell us the “VENDOR_SECURITY_PATCH” level of the device, which may or may not match the Android Framework security patch level. For instance, a device may be running on the latest April 2018 framework patches along with February 2018 vendor patches. By distinguishing between the two security patch levels, it’s possible that Google intends to let OEMs ship the latest Android OS security patches even though vendors haven’t provided updated patches for that monthly patch level.
Alternatively, Google may just display the minimum of the two patch levels (alongside possibly the bootloader and kernel patch levels) in order to more accurately show to the user what security patch their device is on. We don’t yet have confirmation on the intention behind this patch, but we hope to find out more soon.
Google Pixel 2 XL on Android P Developer Preview 1 with March 2018 Security Patches
At the very least, this will be helpful for those of us on Project Treble Generic System Images (GSIs) and other AOSP-based custom ROMs as often custom ROMs only provide framework updates without patching all of the vendor, bootloader, and kernel patches that are specified in a monthly security bulletin, so the mismatch causes confusion among users as they think they are running the latest patches when in reality their device is only partially patched against the latest monthly security bulletin.