[g_p]

Not directly an answer, but one of the big issues with security patches for custom ROMs is the amount of patches they don't (read can't) ship. The proprietary blobs are very often not patched when the device is vendor-supported, and once it reaches end of life from the vendor (but the community ROMs give devices significantly extended longevity), there's no more patches to these blobs.

Blobs incorporate the modem, baseband firmware, bootloaders, and many (most?) of the hardware drivers and imaging drivers.

51% of Android kernel vulnerabilities in vendor drivers are a result of missing or incorrect bounds checks, and over the whole Android kernel, 44% of all vulnerabilities were missing bounds checks, and 12% for null pointer dereference.

Looking across the whole kernel, from Jan 2014 to April 2016, 85% of kernel bugs are born in vendor drivers, with the remainder in the core kernel.

Vendors therefore are shown to write bad code. It's fairly safe to assume this is reflective of the quality of their blobs too - there's certainly a load of vulnerabilities in those if you look at the Android Security bulletins for bugs without a source reference for the fix.

So agreement with your concern, but I'd just like to highlight that custom ROMs are not really a good security solution, as there's just so much to fix (at a kernel level, requiring detailed driver knowledge of the vendor/SoC stuff), and blobs that won't get updated after the vendor abandons the phone.

Ref: https://events.linuxfoundation.org/sites/events/files/slides...

[gsnedders]

Oh, that's totally true—though for many having some secure updates would be better than none, especially given the number of kernel bugs that are only locally exploitable (i.e., if the rest of the system is up-to-date, locally exploitable issues are less, but not none, of a concern).

One thing I wish there was more visibility of is "is this device still getting security updates", because there's often almost no visibility about that (and while you obviously can't say the vendor won't fix future vulnerabilities, you can say whether the vendor has fixed all known vulnerabilities), even online, yet alone anything pushed to the device to let its user know it is no longer secure.

e.g., http://web.archive.org/web/20161224231459/https://wiki.cyano... is the old CyanogenMod wiki page for the Galaxy S2: the last "development channel" (i.e., unstable) build is 2016-12-18, the last "release channel" (i.e., stable) build is 2015-11-16. There is nothing on the device page to suggest the stable build is known to be insecure (though given the number of Android bugs found in the last year unquestionably is!), yet alone anything about upstream vendors dropping support for the device and the unstable build being known to be insecure too. How is LineageOS going to do better than that? That's a damn low bar.

[g_p]

Absolutely - userland is the easiest to exploit, as it's fairly common across all devices (thanks to CTS and standardisation of the runtime) - that's why stagefright was such a big deal!

Definitely agreed - I've thought about making such a list to give visibility of this before, but it would be more of a user-submitted list (perhaps with link-up to screen scraping of OEM web pages for the ones that list the latest version).

What held me back was the sheer complexity of working out whether a device still gets updates - take Samsung as an example; the user says "I have a Galaxy S6". Depending on their geographical location this might be a carrier-free G920I or G920F. If they are in the US, it could then be one of about 5 or 6 variants, and there's even a G920W8 for Canada.

User wants to know if "Galaxy S6" is safe and secure, but even different regional firmwares of the same SKU might not be getting pushed security updates. And some US carriers (Verizon, ATT) are notorious for not pushing out updates to users. And then finally when you figure out the version on a given phone, you need to try to decide if the fact the device is still on October 2016 security patch means it's unsupported or not.

Often Samsung are lagging 2 to 3 months behind on some SKUs, making it even harder to tell. The same is true for many other OEMs - Sony have a pretty complex system of ROMs for each region, meaning you have carrier and non-carrier ones, and they can be on different versions.

To make this happen, we'd ideally need a single worldwide firmware without carrier changes/tweaks/influence. Until then, I suspect it would be too complex to help users work out if their device was being supported.

[vbernat]

Starting from Android 6, it's easy to check if the device is up-to-date from an Android point of view: in "About phone", you have an "Android security patch level" section which should be match the current month.

[g_p]

Yes indeed - the downside of this is that it's hard to gather this information together in a way that lets you show people "which devices" are still maintained.

It is much better for users to know if they are on the latest build. Sadly though for (most/many?) devices, the answer is "it's not", and there's nothing they can really do about it, either due to OEM latency in releasing updates, or the OEM having abandoned their phone.

Samsung [1] and LG [2] pretty much say on their own websites that only certain phones will get updates promptly (or at all) - consider their full product ranges and the cheaper devices not even listed!

[1] http://security.samsungmobile.com/introsm.html

[2] https://lgsecurity.lge.com/security_updates.html > Depending on regions and carriers, updates may be released monthly, quarterly or irregularly.

[gsnedders]

I presume the OS can at least tell what exact model it's on, which means we could potentially at least have something (an app, given I guess Google will never ship such a thing) that says, "hey, this device isn't secure any more".

Now, obviously there's the problem with the time taken to ship fixes (do you say the device is insecure for the two-to-three months before a patch is shipped? do you say the device is insecure only six months after the exploit becomes public? etc.), so even this isn't that simple.

I still wonder about how well the "Android security patch level" will cope with OEMs and their often slow kernel updates (i.e., the fact there are OEMs that quickly release userland fixes, and very slowly release kernel updates).

[BuuQu9hu]

The only solution seems to be reverse engineering the blobs and mainlining Linux kernel drivers, without both of those security updates get much much harder to impossible.

I've no idea how to achieve that on volunteer time, maybe a crowdfunded reverse engineering and mainlining org could work?

[kelnos]

One problem is that RE is time consuming (regardless of whether or not someone is paid to do it), and the useful life of phones tend to be much shorter than other kinds of devices, so digging apart a blob on one phone is likely to have a limited useful lifetime.

And for phones that the manufacturer actively supports, often a new version (especially if it's a new Android version) means new blobs to RE.

When you consider a lot of phones lose a ton of their user base after 2 or 3 years, it becomes much less attractive to even bother.

[BuuQu9hu]

The alternative; devices with no updates and no support outside their original OS, doesn't seem very attractive either.

Maybe we can create incentives for manufacturers to do this work themselves, but I doubt that will ever happen, unless maybe we start getting obnoxious viruses like there were on the PC at one point?

[kelnos]

Sure, that's not a particularly attractive outcome, either.

I just think it's unrealistic to think paid RE work is going to fill this need.

I think there are two realistic options: 1) the manufacturers suck it up and agree to support devices with timely updates over a longer lifespan, or 2) manufacturers open-source every bit of software that runs on the device.

#2 seems less likely, given that a lot of hardware is driven in part by loadable firmware these days. On the other hand, if that firmware is chipset-specific and not device-specific, and the chipset manufacturer can commit to releasing security updates for those, at least 3rd-party OS images could pull them in without help from the device manufacturer.

But really, it's all about demand: Apple tends to support hardware with new releases for 4-ish years as a matter of course, and i-device users are accustomed to expecting that. Android users just don't expect that, and your average user doesn't understand security enough to get why that's such a big problem. They likely mostly just think, "oh well, I won't get the new shiny Android version Jane has on her new phone, that's ok". If average users can be educated to the point where they will switch manufacturers if they're not getting security updates for the useful life of their phone, the manufacturers will listen to their declining sales. I just don't expect that to happen.

[gsnedders]

I wouldn't be surprised if it were easier to backport kernel security fixes to the version the blob depended on than reverse engineer the blob, given the relatively short life of devices in general.

That said, neither of those two options is easy!