Too many perfectly usable phones are put into a questionable security situation by lack of vendor support for keeping key software up to date.
But what’s the actual risk of using an Android phone on a stock ROM without updates? What’s the attack surface?
It seems like most things that’d contact potentially malicious software are web and messaging software, but that’s all done by apps which continue to receive updates (at least until the android version is entirely unsupported) eg. Webview, Firefox, Signal, etc.
So are the main avenues for attack then sketchy apps and wifi points? If one is careful to use a minimal set of widely scrutinised apps and avoid connecting to wifi/bluetooth/etc. devices of questionable provenance is it really taking that much of a risk to continue using a device past EOL?
Or do browsers rely on system libraries that have plausible attack vectors? Perhaps images, video, font etc. rendering could be compromised? At this point though, that stack must be quite hardened and mature, it’d be major news for libjpg/ffmpeg to have a code-execution vulnerability? Plus it seems unlikely that they wouldn’t just include this in webview/Firefox as there must surely be millions of devices in this situation so why not take the easy step of distributing a bit more in the APK?
I’m not at all an Android developer though, perhaps this is very naive and I’m missing something major?
To be fair, unless you’re using some incredibly obscure phone, chances are a ROM exists to keep it up to date long after the manufacturer has walked away from it.
I realize not everyone has the know how to install one, but if they’re concerned, it’s not hard to find someone who does. (we’ve all got techie friends, and if you don’t, that means it’s YOU).
Heck, my pixel 2XL was updated to the newest Android version up to last year thanks to the Pixel Experience ROM. Would likely still be updated if I hadn’t finally upgraded.
You can update your phone with custom ROMs, but it won’t update the closed source components of it(device drivers, bootloader, etc…). If a vulnerability is found in one of those components, it’s unlikely that it will get parched
I think those kind of vulnerabilities are pretty rare, though. If one is discovered while the phone was in widespread use, then hopefully it will have been patched, but after that attention will be focused on finding exploits to newer, more popular phones.
Really, most of the things you need to worry about are in the software, so updating that with custom ROMs should fix the vast majority of potential issues.
I think those kind of vulnerabilities are pretty rare, though.
Not really… If you go read the security bulletin from google, you will see every month that there are a couple of issues fixed on closed source components https://source.android.com/docs/security/bulletin/2023-07-01
Also vulnerabilities related to kernel code, I highly doubt most ROM “developers” are actually backporting security fixes for that specific device’s kernel branch/source.
Old phones stay hydrated.
The vast majority of Android phones in the USA are locked. It has been impossible to upgrade the ROM on any flagship Galaxy for the better part of a decade here, and the few times it is possible, it’ll also trip Knox and disable important features permanently.
laughs in Huawei
Hi! I am a security researcher learning Android, and the system is even more robust than you describe. Not only are applications maintained separately once you lose vendor support, but mainline modules continue to provide updates to commonly targeted omponents. Stagefright type bugs are highly unlikely because if such a bug was found, Google can and does simply update the media module irrespective of vendor support.
It’s more accurate to say that when you lose security updates you are now getting a reduced selection of patches. You correctly identify that firmware for some components is not going to be updated anymore. There is definitely an increased risk, but it’s also incorrect to claim that you’re not getting any security updates.
I don’t advise intentionally running software with known security vulnerabilities. Some vulnerabilities will be patched, but not all, if your device no longer receives security updates from the vendor.
Thanks, that’s encouraging and very relevant. Looks like it was introduced in Android 10 and aside from “Project Mainline” is referred to as “modular system components”: https://source.android.com/docs/core/ota/modular-system
Can you shed more light on what someone would be risking by continuing to use an EOL device? You say you don’t advise it, but it’d be helpful to elaborate on why.
It seems like the increased vulnerability would be relatively limited: I presume the browser and messaging are by far the most common vectors and those would be as up to date as ever but I can see how exploiting an unpatched vuln there on an unsupported device could have more impact as it would give more options for privilege escalation.
Otherwise it’d be something RF based. Aside from widely publicised things like BlueBorne (that we should be keeping an eye out for anyway), is it a reasonable concern that there are identify theft rings employing people with modified hardware wandering around subway systems trying to exfiltrate credentials from devices with specific vulnerable basebands? Seems like Android also offers some defence in depth there that’d make it unlikely enough to ensure it wouldn’t be worth their while?
There are a few technologically disinterested people in my life that I advise (as is no doubt the case for many here) and I don’t know how strongly to push for them to get new devices once theirs fall out of support. Most of them are quite content with what they’re using and are not in the habit of installing apps (and will reliably ask me first) so they really would be replacing the device solely for the updates. In some cases it’s not only the time and effort to decide on a replacement and get things transferred over but the expense can also be a burden. So I don’t want to raise the alarm lightly.
I’ll do my best to respond, but I’m not sure if this response will satisfy you.
By continuing to use an EOL device, you are conceding that there are bugs which are known and documented that have not been fixed on your device. The kernel for example (except for extremely recent devices) is very specific to your handset and will no longer receive updates. A bug in the kernel, if exploited, could potentially result in a total compromise of your device security.
Let’s imagine that you’re concerned about browser exploits. Your browser will be up to date, but let’s imagine that there’s a zero day that gets exploited. Now, an attacker can combine their brand new bug with an already known bug in your kernel that hasn’t been updated yet to break out of the app sandbox and gain access to your device. This isn’t terribly outlandish. It’s common for attackers using a browser exploit to perform some analysis of the environment to select the next stage that is most appropriate for the device under attack. Because you ran older system software, you lowered the browser exploit bar by -1 exploit the attacker had to discover. Now, it’s likely the exploit will be discovered and the browser patched quickly, but there is still a time window where you are more vulnerable than someone who has an up-to-date kernel, and there have been cases where bugs existed for many years before they were discovered.
Let’s talk about exploits over RF. Your baseband might become very outdated and let’s say there is a known security bug. An attacker runs a fake cell tower and steps onto your modem. Now, presumably if you’re also running an old kernel, an attacker has documented issues that they could research and leverage for stepping from the modem into the kernel. When you are running old code, you make it easier for the attacker. They don’t have to get as creative because they have a library of issues to choose from.
An exploit over the baseband would have to be tailored to your specific baseband and your specific kernel. It could theoretically happen, but the odds of this happening to you are quite small because it would have to be crafted to your specific setup. For most users, attackers would like to use an exploit that applies to a wide variety of targets. Most of the common software that would be targeted has become modular and easily updated. We hope that good design of Android means this attractive and wide-ranging exploit would be hard to pull off even if you are EOL.
There’s no such thing as a perfectly secure device. Ultimately, it’s about increasing the cost and difficulty for the attacker until targeting you is simply not worthwhile. When you use an EOL device you go from highly unlikely to unlikely. It’s still unlikely. Does this matter for your use case? It might. I’m a security researcher, so it’s not unthinkable that I might be specifically targeted. However, me being specifically targeted would be even more likely if I were a celebrity or a diplomat. In that case, it would be very important to me to force an attacker to discover new bugs just for me. Think of it like cryptography. There is no unbreakable encryption aside from the one-time pad. The objective is to drive up the cost so high that it’s effectively unbreakable for practical purposes. Security is much the same way.
There’s not going to be a straight answer to this. Are you a nobody or are you a valuable target? Would your attacker be dedicated or opportunistic? Are they well funded, or a script kid? Ultimately it comes down to how much risk you’re willing to tolerate. Android is designed to try to give you a better deal even when your device is EOL. Quantifying how much of a difference it makes is not trivial. It really depends.
For what it’s worth, I let my dad use a three-years outdated version of Android. He doesn’t do banking on that phone. He doesn’t care. It’s a phone. No one is going to specifically target him for his precious browsing history. His device getting owned by a browser exploit is unlikely and in the event it does happen it is merely an inconvenience.
For myself as a security researcher? If my financial situation looks good, I want the security updates. I feel that I am at elevated risk, but it’s still unlikely someone would go after me specifically. I wouldn’t have severe heartache with being outdated for a little while even though it’s still not advisable. For me and my father it would be an understood and accepted risk.
Really appreciate you taking the time to write that. I have a sense of most of that (“defense in depth” and “threat model” are good lenses to think about such things through for sure!) but what I was trying to get a better grasp on was how much risk from automated attack was a normal person without worries of an “advanced persistent threat” taking on by using a device past EOL. Like you say, “Quantifying how much of a difference it makes is not trivial” so I feel less conflicted to know that you’re comfortable with your dad taking that risk.
I would think that the main thing at stake for a typical user isn’t just browsing history or email though but rather identity theft since a successful attacker can use the device to get through 2FA.
Perhaps the best way I can put that concern is that the risk is real but the risk is low. Good common sense operational security measures such as not clicking on things that you’re not familiar with, sticking with a small set of well-known applications from trusted sources, and turning off features or taking away permissions that you don’t need goes a long way to reducing your risk. You cannot eliminate the risk entirely, and while I don’t recommend running without security updates, I don’t think it’s a completely irrational choice. I believe that it’s incorrect to categorically declare that it’s unsafe and unacceptable for any use case.
As I’m sure you can appreciate, security is not a boolean. If you’re no longer getting vendor security updates it’s another risk factor that you need to consider.
They will soon pass a law in France where they can remotely enable GPS, audio, camera. That’s the kind of problem you will encounter if your phone has OS backdoor due to lack of updates and a shitty government.
If your phone is old and obselete, then your OS likely lacks the backdoor that will now be required by the government to be installed in order to facilitate the Guantanamo-fication.
Backdoor in the sense of CVE i mean, not backdoor introduced by the government.
That’s not what you said though. You mentioned the government backdoors, which can only really apply to new phones (or updates to existing phones). Common Vulnerabilities and Exploits is a separate issue, where if you have an older phone there’s a greater chance it will have an unpatched vulnerability.
No i said 2 things: OS backdoor, and shitty government that passes laws to snoop on their citizen. But i agree that vulnerabilities makes more sense.
There’s no difference. If the government can get in, so can criminals.
deleted by creator
deleted by creator
Play Store apps are almost never going to be the problem in this context.
Privacy? Yes. Security? Probably no.
If we look at some critical CVEs(eg. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-20222) in the past, they are mostly in system libraries.
I don’t think they are things that can be fixed on the app level?
I don’t think they are things that can be fixed on the app level?
Indeed not. So I’m trying to better understand how vulnerabilities at the system level are exploited. It seems like the attack surface is limited to RF (bluetooth/wifi can be turned off if one is willing to make that compromise), app install (many just use a small selection of well-trusted apps), and messaging/browser which are regularly updated if the device is properly configured.
Based on this thread I’m beginning to form the opinion that it is not unreasonably foolhardy for someone to continue to use an unsupported device if they are willing to make the compromises necessary to limit their attack surface.
It’s a bit hard to find the details of the vulnerabilities let alone POCs.
I would assume the APIs provided by android use the underlying system libraries so if left unpatched then any app that makes use of the APIs could potentially be an attack surface? This is all my assumption and it would be nice for someone that specialises in Android security to comment.
The app, in the scenario where we’re trusting the author/store, is only part of the surface to the extent it’s exposed to a potentially malicious payload. eg. a trusted solitaire game using a vulnerable API doesn’t exacerbate that vulnerability because it doesn’t expose it to untrusted input whereas a PDF viewer would because the PDF could be coming from anywhere…
Vulnerabilities in the baseband chip mean that, whether it runs a custom operating system or not, all old phones should be considered compromised.
Such vulnerabilities are impossible to fix or mitigate because the baseband firmware is proprietary, exists outside the operating system, is responsible for communicating with the outside world (meaning literally anyone can attack it at any time), and has unfettered access to the entire phone (meaning it can take over the operating system).
Don’t use an old phone for anything unless you’re comfortable with some overseas crime ring seeing it.
Just to make it clear: flashing a different OS will not protect you!
It’s not necessarily true that the baseband has unfettered access to the entire phone. Pixel devices for example use a special IOMMU to restrict what the baseband can access, forcing it to go through a specialized interface only. It still requires more work for a compromise of baseband to get control of Android.
First you need to exploit the baseband. Then, you need to exploit the kernel.
Now, that’s a significant attack surface, but the point stands that many phones now have some compartmentalization because of this risk. This has been a concern for some time and newer designs are trying to mitigate it.
Here’s a security evaluation of the pixel which shows that a compromise of the modem does not equate to an immediate compromise of the device. The modem must be restricted in what it can access of the application processor.
That’s good news, but GrapheneOS does not support older Pixel phones because they are insecure and cannot be made secure, so apparently the baseband isn’t the only problem.
Unfortunately, they’re not specific about which firmware poses a security threat unless updated. I was under the impression that the baseband firmware is the problem, but I must have been mistaken.
