> The vulnerabilities are found in Qualcomm’s software drivers that come with its chipsets. Pre-installed on devices at the point of manufacturing, these vulnerable drivers can only be fixed by installing a patch from the distributor or carrier. Distributors and carriers can only issue patches after receiving fixed driver packs from Qualcomm.
> The research team provided Qualcomm with information about the vulnerabilities in April 2016. The team then followed the industry-standard disclosure policy (CERT/CC policy) of allowing 90 days for patches to be produced before disclosing these vulnerabilities to the public.
> Qualcomm reviewed these vulnerabilities, classified each as high risk, and confirmed that it released patches to original equipment manufacturers (OEMs).
The complexity of this is really a problem for security updates.
It's bad enough for Android updates: the OEM packages it and adds their stuff, then the carrier packages it and adds their stuff. A firmware update like this is yet another layer..
While Checkpoint did the right disclosure thing here, I notice they don't mention how far down the patches have gotten, or how many users are still vulnerable today.
>I notice they don't mention how far down the patches have gotten, or how many users are still vulnerable today.
There were a handful of "Critical" Qualcomm specific bugs fixed in the July [0] and August [1] Android security updates.
I can tell you that my Nexus 5X, which is on the July patch level, is still vulnerable to 2 of the bugs according the checkpoint security scanner. One is listed as being fixed in the August update, the other isn't.
Better 'a someone' on the Nexus 5 than 'a series of someones' (e.g. Qualcomm, Google, HTC, and Verizon) on any non-Nexus phone, only some of which have any vested interest in getting you those updates.
There’s a reason we modularized drivers on other systems, which allows people to customize the OS however they want it, because the firmware, drivers, main OS, UI layer of OS, and applications are all properly seperated.
Ah, so I have the source code for the kernel to patch it manually?
I have the source for the firmware to patch that manually, too?
You are still proposing I run proprietary software that can be abandoned at any time, and where I have no way to continue fixing it if it is abandoned.
We’ve seen that with several Nexus devices before, the chipmaker abandoned the SoC, Google couldn’t fix issues because of that, and we didn’t get OTAs from anyone to fix things.
> The research team provided Qualcomm with information about the vulnerabilities in April 2016. The team then followed the industry-standard disclosure policy (CERT/CC policy) of allowing 90 days for patches to be produced before disclosing these vulnerabilities to the public.
> Qualcomm reviewed these vulnerabilities, classified each as high risk, and confirmed that it released patches to original equipment manufacturers (OEMs).
The complexity of this is really a problem for security updates.
It's bad enough for Android updates: the OEM packages it and adds their stuff, then the carrier packages it and adds their stuff. A firmware update like this is yet another layer..
While Checkpoint did the right disclosure thing here, I notice they don't mention how far down the patches have gotten, or how many users are still vulnerable today.