Google has been publishing monthly security bulletins since August of 2015. These security bulletins contain a list of disclosed security vulnerabilities that have been fixed which affect the Android framework, Linux kernel, and other closed-source vendor components. Every vulnerability in the bulletins was either discovered by Google or disclosed to the company. Every vulnerability listed has a Common Vulnerabilities and Exposures (CVE) number, along with associated references, the type of vulnerability, a severity assessment, and the AOSP version affected (if applicable). But despite the seemingly simplistic process behind how Android security patches work, there’s actually a somewhat complicated back-and-forth behind the scenes that allows for your phone to get monthly or (hopefully) near-monthly patches.
What actually makes a security patch?
You may have noticed that every month, there are actually two security patch levels. The format of these patches is either YYYY-MM-01 or YYYY-MM-05. While the YYYY and MM obviously represent the year and month respectively, the “01” and “05” confusingly does not actually signify the day of the month in which that security patch level was released. Instead, the 01 and 05 are actually two different security patch levels released on the same day every month – the patch level with 01 at the end contains fixes to the Android framework but not vendor patches or upstream Linux kernel patches. Vendor patches, as we defined above, refer to fixes to closed-source components such as drivers for Wi-Fi and Bluetooth. The security patch level signified by -05 contains these vendor patches as well as patches in the Linux kernel. Take a look at the table below which may help in understanding.
| Monthly Security Patch Level | 2019-04-01 | 2019-04-05 |
|---|---|---|
| Contains April Framework Patches | Yes | Yes |
| Contains April Vendor + Kernel Patches | No | Yes |
| Contains March Framework Patches | Yes | Yes |
| Contains March Vendor + Kernel Patches | Yes | Yes |
Of course, some OEMs may opt to roll their own patches and updates into security updates as well. Most OEMs have their own take on Android, so it only makes sense that you may have, for example, a vulnerability on a Samsung phone that doesn’t exist on a Huawei. A lot of these OEMs also publish their own security bulletins.
The timeline of a security patch from Google to your phone
Security patches have a timeline roughly spanning about 30 days, though not every OEM can avail of the full length of that timeline. Let’s take a look at the May 2019 security patch for example, and we can break down the entire timeline behind the creation of this patch. Companies like Essential manage to get out their security updates on the same day as the Google Pixel, so how do they do it? The short and simple answer is that they’re an Android partner. The May 2019 security bulletin was published on the 6th of May, with both the Google Pixels and the Essential Phone getting near-immediate updates.
What it means to be an Android Partner
Not just any company can be an Android Partner, though admittedly basically every major Android OEM is. Android Partners are the companies that are granted a license to use the Android branding in marketing material. They are also allowed to ship Google Mobile Services (GMS – refers to pretty much all Google services) so long as they meet the requirements outlined in the Compatibility Definition Document (CDD) and pass the Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS), and a few other tests. There are distinct differences in the security patch process for companies that aren’t an Android Partner.
- Android framework patches are available to them after being merged into AOSP 1-2 days before the security bulletin is released.
- Upstream Linux kernel patches can be cherry-picked once available.
- Fixes from SoC vendors for closed-source components are available depending on agreements with the SoC vendor. Note that if the vendor has given the OEM access to the source code of the closed-source component(s), then the OEM can fix the issue(s) themselves. If the OEM does not have access to the source code, then they must wait for the vendor to issue a fix.
If you are an Android Partner, you immediately have it a whole lot easier. Android partners are notified of all Android framework issues and Linux kernel issues at least 30 days before the bulletin is made public. Google provides patches for all issues for OEMs to merge and test, though vendor component patches are dependent on the vendor. Patches for the Android framework issues disclosed in the May 2019 security bulletin, for example, were provided to Android partners at least as early as March 20th, 2019*. That’s a lot of extra time.
*Note: Google can, and often does, update the patches for the latest security bulletin all the way until the public release. These updates can happen if new vulnerabilities and bugs have been found, if Google decides to remove certain patches from the monthly bulletin due to it breaking critical components, if Google updates a patch to resolve a bug created by the previous version of the patch, and other reasons.
Why do I need to wait so long to receive a security patch on my phone?
While it’s true that Android Partners (read: all major OEMs) received security patches well in advance of their release, many are painfully aware that they possibly won’t receive a security update for months after its release. This is generally down to one of four reasons.
- OEMs may need to make heavy technical changes in order to accommodate a security patch, as it may conflict with existing code.
- The vendor is slow at providing update source-code for closed-source components.
- Carrier certification may take time.
- Companies may be unwilling to release a security update without also releasing a feature at the same time.
While all of these are valid reasons for a business not to release a security patch, the end-user doesn’t always care about any of those. Admittedly, the end-user doesn’t always care about security patches either, though they should. Initiatives like Project Treble, extended Linux LTS, and Project Mainline are helping to eliminate the technical difficulties of merging these security patches, but it’s not enough to make OEMs consistently strive to put out updates. With a Generic Kernel Image, or GKI, SoC vendors and OEMs will have an easier time merging upstream Linux kernel patches, though we likely won’t see the first devices with GKI until next year.
But an interesting piece of information that most don’t know is that major OEMs must provide “at least four security updates” within a year of a device’s launch, and 2 years of updates overall. Google has not confirmed these specific terms, but the company did confirm that they “worked on building security patching into [their] OEM agreements”. As for Android Enterprise Recommended (AER) devices, devices are required to get security updates within 90 days of release for 3 years. Rugged AER devices are required to get 5 years of security updates. Android One devices are supposed to get security updates every month for 3 years.
What’s in a security patch?
A security patch is just another update, though generally a lot smaller with changes to individual frameworks and system modules rather than system-wide improvements or changes. Each month, Google provides device OEMs with a zip file that contains patches for all major Android versions currently still supported, along with a security test suite. This test suite helps OEMs catch gaps in security patches, to ensure that they don’t miss anything and that the patches were merged appropriately. As the month goes on, Google may make minor revisions such as deciding that one specific patch is optional, specifically if there are troubles implementing it.
What about custom ROMs?
If your smartphone doesn’t get many security updates, that doesn’t necessarily mean you’re better off switching to a custom ROM. While true that you will get security updates that you would not have gotten otherwise, that’s only half of the story. Unlocking your bootloader leaves you susceptible to physical attacks on your device, even if on the software side, security is hardened. That’s not to say you shouldn’t use custom ROMs, it’s just that there are other concerns when it comes to using them that don’t apply if your bootloader is kept locked. If you’re more worried about the software side of things, then you’re still better off with a custom ROM that gets frequent security patches.
But remember we talked about the difference between YYYY-MM-01 and YYYY-MM-05 patches? The -05 patch level contains Linux kernel patches as well as vendor patches – patches applied to closed-source software. This means custom ROM developers are at the mercy of whatever OEM they’re developing for, and if the OEM releases update blobs or not. This is fine for devices that are still updated by the manufacturer, but for devices that aren’t, the patches applied can only be applied to the Android framework and the Linux kernel. This is why LineageOS‘ Trust Interface shows two security patch levels – one being platform, the other being vendor. Even though custom ROMs for unsupported devices can’t fully integrate all of the latest patches, they’re going to be more secure than the older, outdated ROM.
The post How Monthly Android Security Patch Updates Work appeared first on xda-developers.
from xda-developers https://ift.tt/38dexPX
via IFTTT
Aucun commentaire:
Enregistrer un commentaire