You need these critical Android updates – but will you get them?

Google’s latest Nexus Security Bulletin is out.

The February 2016 updates were announced yesterday, making it what you might call a “partial patch Monday.”

Google told its commercial partners about the month’s security holes back at the start of 2016, but the fixes will only be released to the Android Open Source Project (AOSP) over the course of today or tomorrow.

That’s ironic, considering Android’s open-sourced, GNU Public Licensed core – you might expect the GPL to come first in all of this – but the delay is presumably a way of letting keen Nexus users get their updates installed before at least some of the bugs get openly “documented” in the AOSP files.

Of course, the current wave of updates only apply to Google’s Nexus devices.

If you have a device from a different vendor or carrier, your mileage may (indeed, probably will) vary.

Additionally, the updates only apply to some Nexus devices.

Unfortunately Google doesn’t bother to list explicitly which Nexus models are excluded from what it calls, simply, “Nexus devices.”

You can head over to the official Android Nexus firmware pages to try to find out; as far as we can see, the Nexus 7 2012 and the Nexus 4 are stuck on unpatched versions of Lollipop (Android 5), and the Nexus Q and earlier devices are effectively abandonware, with old Android 4 releases the most recent you will get.

The bug fixes this month include five listed as critical:

The first two vulnerabilities on the list are the most critical of the criticals, because they allow remote code execution.

In the case of the Broadcom Wi-Fi driver bugs, anyone else on the same network as you (at the coffee shop, for instance) could trick your Android into running malware.

Google’s bulletin doesn’t say, but we’re guessing that the Broadcom bug is essentially an elevation of privilege flaw at the same time, assuming that any remotely-injected code runs in the context of the driver, thus giving it kernel-level powers.

The Mediaserver bugs probably sounds familiar, and so they should: this is essentially Stagefright all over again.

Mediaserver is a core Android component that provides the code needed for processing and then displaying or playing a wide range of image, video and audio files.

Unfortunately, handling multimedia files safely needs incredible care when programming, due to the complexity of the many file formats involved, and the risk of memory-related bugs when trying to convert files such as heavily compressed videos into a sequence of individual image frames for display.

Any image or audio rendering software that sometimes crashes when reading corrupted files may be exploitable, if the crash can be cleverly orchestrated by a crook who crafts a corrupt file that misbehaves predictably (if that is not an oxymoron).

Worse still, multimedia files often get processed automatically during mailing, web browsing and instant messaging, which gives crooks multiple ways to sneak in using booby-trapped files.

Unfortunately, to be competitive, multimedia rendering software has to have as many features as possible so it can handle just about any file type that users might want to view or listen to.

But to be secure, it really ought to cut back on the number of file formats it can handle, and on the number of obscure features that it can deal with in each supported file type.

This makes the code easier to audit, and less likely to contain rarely-used components that simply haven’t had enough scrutiny or testing over the years.

Given the prevalance of multimedia-related bugs that have shown up in Android since the world went looking in earnest in 2015, when Stagefright was announced, perhaps Google will consider a configuration setting that removes support for all but the most prevalent formats as a way of reducing your attack surface area?