I guess, but it sure is nice that on Apple hardware you generally don’t need to worry about doing this calculus because they deliver updates in a timely manner to even five year old devices.

It bums me out that them doing this hasn’t been effective in shaming everyone else into following suit.

According to Wikipedia the Pixel 2 received security updates for less than 3 years. None of their devices got more than 3 years 3 months of updates. That should be illegal honestly, couldn't be more clear that they don't care about sustainability.

https://en.m.wikipedia.org/wiki/Google_Pixel

If you could demonstrate harm from a vulnerability, you could probably ask a court for some compensation.

Just like if your lawnmower exploded with a known flaw, you would sue the lawnmower manufacturer.

Qualcomm's lack of support for older chipsets has been blamed for the short lifecycles of these phones. Pixel 6 and 7, which don't use Qualcomm SoCs, both get at least 5 years of security updates.

Google is ten times the size of Qualcomm— there's no way they wouldn't be able to extract those commitments upfront.

Google is, but most of Google isn't (wasn't) purchasing SoCs from Qualcomm. Its hardware division is tiny.

I still remember when phones did not receive any updates, and the few lucky models required developer tools to manually upload the firmware updates, which most of those few selected models only got one in their lifetime.

Not sure if you’re referring here to the BlackBerry era or right back to side-sliders and razr flips, but either way, both the stakes and the attack surface were way lower back when there were no apps and phones really were just for calling and texting.

Brew, Symbian, Java ME and Windows CE/ Pocket PC, Palm era.

Plenty of apps and networking in Europe and Asia.

Fair, okay— as soon as email, payments, or banking is involved then you have a juicy target and you need a device that's secure end-to-end.

The iPod Touch Gen 7 lasted just under 3 years from release. They may be better than many others but I just got bit by that one.

That is unfortunate. Certainly the trend has been for them to lengthen the support window over time— see this article for a decent summary: https://www.macworld.com/article/675021/how-long-does-apple-...

I wonder if Apple views the "iPod" branding as being more associated with gaming and consumption and therefore less important from a security standpoint. I don't think I necessarily would agree with such a stance when the exact same hardware can carry sensitive stuff like a password manager, banking and medical apps, and so-on. But I imagine their telemetry showed that that overwhelmingly wasn't the case, so it was easy not to prioritize it.

No, it's more that Apple has always released iPod with older chips, and in this case it also decided to discontinue that product line, which meant that they dropped software support for it relatively soon.

Every flagship iPhone since 2011 has gotten at least five years of both OS updates and security updates, with some newer devices (including the $399 iPhone SE) getting as many as seven years.

Even after official support completely ends, Apple tends to go back and issue patches for active exploits. The nine year old iPhone 5s just got another security update a couple of months ago.

This may be a special case: "With the release [of iOS 16], Apple dropped support for iPhone and iPod Touch models with A9 and A10 Fusion chips (the iPhone 6S/6S Plus, the 1st gen iPhone SE, the iPhone 7/7 Plus and the 7th gen iPod Touch) due to hardware limitations and Chinese government's border stringent in response of COVID-19 pandemic." https://en.wikipedia.org/wiki/IOS_version_history#iOS_16_/_i...

> The iPod Touch Gen 7 lasted just under 3 years from release.

It was released May 2019, and it just received its latest security update (15.7.3) January 23, 2023. Presumably that is not the last security update for iOS 15.

That’s an important note— getting the latest iOS is nice, but Apple continues to patch the 3-4 most recent versions.

I’m not aware that Android gets anything like this, even in the era of Google Play Services.

With a cursory search I found CVE-2021-0316. This one's just for bluetooth, but it's an RCE with no user interaction discovered in 2021. Pixel 2 had its last security patch in November 2020.

Yes, it exists, but is it actively exploited? A cursory search turns up no working exploit code. Given modern exploit mitigations many theoretical vulnerabilities turn out to be nothing-burgers, as far as I can see there's certainly no worm running around popping phones with it.

For sure, if you're paranoid or a high-value target, update, buy a new phone. But normal users don't need to care unless there's actually something on the line.

Android's security advisory page shows what vulnerabilities have been found in the wild. Security researcher Maddie Stone from Google's Project Zero:

https://twitter.com/maddiestone/status/1395004346996248586

Not sure what to say about encouraging users to throw caution to the wind. We got to this point of such good exploit mitigation because it's good for everyone for these devices to be secured.

A bit silly to link a page about malware that Play Protect prevents, largely local privescs that are being detected by the OS or Google Play beforehand.

An average user installing apps from Play Store has nothing to worry about for those. That's kind of the point.

It's great for these devices to be patched - I'd love it if Google would take more control over the ecosystem to be able to patch this sort of thing, but it's much worse for users to just throw out otherwise working devices with limited-to-no real-world security issues.

Um, no? Most of the RCE's I'm seeing are at the OS level and would require upgrading to a newer Android OS version that older devices won't have support for.

To fully patch, yes, but the point is that Play Protect is detecting them before installation before they can be exploited, ie: on submission to Play Store or on installation on devices.

Yes, this is still a risk - if you tend to install random apks from the internet and disable Play Protect or run across an undetected modification of the relevant exploit code. But most users don't do that.

Gotcha. Still, it's a lot of RCE's coming out per month to depend on blackbox machine learning for something people use every day for their personal/business needs.

Google Play Protect has limited capabilities to protect against in-the-wild exploits of the kind Maddie described. It knows about certain packaged implementations, which means that it can offer some defense from off-the-shelf uses of an exploit, but it definitely does not reduce the risk to anywhere near zero. The only correct way to mitigate against exploits like this is a patch, end of story.

Absolutely, but like I mentioned in the prior post, these are local privescs. You basically need to go out and install malicious apps.

If you can use Windows without it getting full of malware, you can handle unpatched Android LPEs too.

Keep in mind, Webview, browsers, email clients, etc are patched via app update mechanisms.

GPU bugs are particularly concerning because they have significant power (the GPU can often map all of physical memory if convinced to do so) and widely exposed (lots of things need graphics). Turning one of these into a full chain can often require zero bugs if the buggy API is callable from JavaScript, or one to escape the VM and poke the driver.

I would like to see stats on what percentage of android phones were exploited in the wild for malicious purposes (ie. excluding cases where the user deliberately is jailbreaking them).

Personally I have never seen any friends or relatives get malware on their phone that gets outside the app sandbox (ie. Uninstalling the bad app seems to solve the issue). Compare that to MS Windows where it seems common for regular users to have malware infested systems.

Generally the fraction is fairly low, because the bar for a full chain these days is pretty high. That said, it is important to not be lulled into a false sense of security because you don't seem like an attractive target. A chain worth $50k dollars can be a good purchase if you think you can bring in a million dollars home with it.

Well, I use a web browser on the phone. Chrome et al. are still receiving updates for my phone, but I'm guessing they use some system components that are not receiving updates? So my main worry is something like an ad network loading an exploit. You don't need to be a high value target to get caught in an extremely wide net like that.

(Yes, I know: get a better ad blocker, etc. — I'd rather have fewer weak links, though, and a lack of basic OS updates is a pretty big weak link.)

Not really - Android has for many versions now been updating the embedded webview component via play services.

Huh, that's somewhat comforting, I guess. And all image codecs etc. are statically linked?

Many are. However, you'd still be vulnerable via API calls to other things, like Binder exploits.

A phone (or any kind of internet-connected computer) that's been completely unsupported for years will presumably be low-hanging fruit for even the cheapest and crustiest of exploit kits.

How? Web browser is kept up to date via other mechanisms: Firefox for Android, Chrome and even the embedded WebView are all updated via Play Store.

That is, to put nicely, forced-obsolescence FUD. They want to scare you away with words like "unsupported" so they can keep you on their leash.

With the state of software development today, I'd be more worried about how many other holes they've added in the process of fixing something or introducing unwanted new "features"[1].

Here's some interesting statistics to look at and compare...

https://www.cvedetails.com/product/462/Microsoft-Windows-98s... - 30 RCEs in 7 years

https://www.cvedetails.com/product/739/Microsoft-Windows-Xp.... - 276 RCEs in 20 years

https://www.cvedetails.com/product/32238/Microsoft-Windows-1... - 664 RCEs in 8 years

https://www.cvedetails.com/product/102217/Microsoft-Windows-... - 157 RCEs in 2 years

More relevantly:

https://www.cvedetails.com/version-list/1224/19997/1/Google-...

[1] https://news.ycombinator.com/item?id=28449607

Are you claiming that unpatched software is more secure than patched software?

He's claiming with the amount of features being added for every security bug fixed in an update a bunch more are added.

However that ignores the fact that publicly known exploits are more dangerous for the average user than zerodays.

It ignores a whole lot more than that. For instance, are we seriously going to pretend that the threat landscape in the Windows 98 and XP eras was anything like what it is today?

Well, I'm not. If he wants to daily drive Windows 98 because it had fewer documented RCE vulns, godspeed to him---and he probably will be more secure, just by virtue of good ol' security through obscurity---but that is not a reasonable solution for 99.999howevermanyninesyouwant% of computer users today.

The threat was arguably exponentially worse during the XP era - Windows boxes with a huge default attack surface were directly connected with public facing IPs to a 32-bit IP space that could be trivially brute-forced by worms. There's a reason we haven't seen anything as bad as Blaster in the past decade: NAT.

The rate of finding exploits and what the definition of a vulnerability is really what has changed - now the definition of is much broader while at the same time, exploitability has dropped off due to mitigation in modern operating systems, compilers and CPUs. Overall, we get far more exploits, but far less of significance.

Yes, it was not my intention to imply that those old operating systems were fundamentally more secure in some way. You're getting at it here: the space has broadened, and asserting that old software is more secure than new software based solely on documented RCE counts is laughable.