Side note: Just checked are non-Android Linux OSes targeted by this spyware. Apparently, there's no public info in favor of such. So probably, nope. It looks mostly targeted against Android and iOS only.
It's safe to assume that any mobile phone OS will inevitably be targeted. There are always going to be unpatched and uncaught vulnerabilities, and the market for finding these vulns are very hot.
The bigger question is why do you think you'd be vulnerable to attack by a nation-state? If you are that prominent, you are screwed anyhow.
This article by Mickens is fairly accurate [0]
[0] - https://scholar.harvard.edu/files/mickens/files/thisworldofo...
Everything which can fit into a pocket and has a HTML5 browser?
FYI, I know about how extremely vulnerable average cellular baseband is (and that it would often use unprotected or weakly protected DMA). Let's assume the device in question doesn't have one of these.
Just about every phone (smart or feature) is running some flavor of Unix (iOS/BSD for Apple, Android/Linux for most other smartphones, and KaiOS/Linux for feature phones).
The 1998 style Nokia brick is functionally non-existent as there is no financially viable demand for a product like that anymore.
The markets that are feature phone driven (much of Africa, poorer regions of South and Southeast Asia) are also heavily WhatsApp dependent, so the mobile OS needs to be lightweight but also support modern app functionality - which lends itself to the embedded Linux use case.
Also, no matter how much you modify and QA code, inevitably some bug will arise, and will be open to exploitation.
Sure, but it runs Android Go (embedded Android) or KaiOS (embedded Linux) out of the box.
Any vulnerabilities that arises in Linux can also be weaponized on those OSes as well depending on when the OS image was deployed and whether or not the OEM supports upgrades and patches (generally they don't)
Anyway, Alpine seem to use musl instead of glibc.
This is a classic example I use when explaining the need for SBOMs and Software Supply Chain Security to non-software C-suite.
My phone doesn't run Xen yet (I've ran into some problems with kexec() support in Linux on aarch64), but it runs KVM just fine ;)
However, it seems that in Debian it's patched https://security-tracker.debian.org/tracker/CVE-2015-0235 . Is what you're talking about Alpine-specific?
I'm not sure, but it's the tip of the iceberg. There are plenty of uncaught and unpatched vulnerabilities across all environments, and plenty that have not been reported because vendors like Zerodium will pay premiums for zero-days.
> Is what you're talking about Alpine-specific?
Yep! That's the point - vulnerabilities can be caught and known, but patching might not be provided, leaving environments open to attack.
> similar bugs may not be even known as of now). Virtualization and containerization-based approaches would be a go-to method for reducing potential surface affected by them
Virtualization as it is today is fairly vulnerable to escapes, but this is why the US Govt has been funding Secure Enclave/Trusted Execution research for 10-15 years now.
Basically, complex vuln-free code is highly unlikely to ever exist. That said, these are very difficult to exploit by some random attacker as these are fairly complex.
If you are at threat of being targeted by NSO Group or Zerodium enabled attacks, you are already on the radar of a country's Law Enforcement/Interior Ministry/Dept of Homeland Security/Intelligence Community and any attacks on your phone are the least of your worries.
Exports of these products are heavily regulated and require sign off from the government (eg. Israeli offensive security products like NSO's Pegasus require sign off from the Israeli MoD and PMO)
Your best solution is to buy a phone that is very well supported and constantly patched by the vendor (Apple, Google, higher model Samsung are fairly well maintained) as they will push critical patches if and when a vulnerability is found.
Feature phones and more generic smartphones won't have that level of support due to margin constraints.
Ah, you mean social engineering attacks and more powerful attacks relying completely outside of the cyberspace (to say more bluntly, which perfectly fits the case here, "in the meatspace"), right?
In terms of broadly-understood virtualization, there's always FPGA with its possibility to spawn multiple number of completely independent softcores. These days some FPGAs with enough computing power for well-optimized security-critical part of general-purpose computing (messaging, web browsing, maybe DSP - not computation like neural models) have fully open-source bitstream synthesis tools.
BTW, thanks a ton for letting me know about the unpatched vulnerability in Alpine. I'll talk to the pmOS guys about patching it.
No. I mean actual unpatched vulnerabilities and exploits that haven't been published.
NVD is just the icing on the cake. Plenty of less scrupulous vendors like Zerodium, Crowdfense, NSO, etc have collected troves of exploits and vulnerabilities that have never been published, because they can pay 2-3x what bug bounty programs pay.
For example, NSO's Pegasus toolkit which has been operational for a decade but only remediated in the past couple months.
But it doesn't matter. If you've been targeted by adversary using one of those products, you are already very high profile and security theatre around your phone's security is basically useless if you don't have a security team to back you up.
> In terms of broadly-understood virtualization, there's always FPGA with its possibility to spawn multiple number of completely independent softcores. These days some FPGAs with enough computing power for well-optimized security-critical part of general-purpose computing
That's what Secure Enclave/Trusted Execution is in a nutshell, but it's progressed way past FPGAs (that was a late 2000s/early 2010s research area before moving up to CPUs and GPUs)
------------
Just stick with a common popular smartphone from a brand that makes sure to consistently be on top of patching and supportability.
It's about as safe a consumer computing device can be, and even nation states recognize that. Most leaders and politicans use common smartphones as well, but they are locked down with an MDM (this is BlackBerry/RIM's bread and butter now because they've deprecated phone manufacturing)
I know very well about Zerodium. However, FPGAs can be way more secure than any kind of ASICs. If you don't understand why, then I don't think further discussion is warranted. I worked with Apple's implementation of security enclaves, and they don't isolate (or "outsource" to be processed there) nearly as much as should be isolated. For example, whole display and touch input needs to go through the application processor, anyway. It's not a good way to go, to say the least. You can't overlay anything on the top of the display nor isolate touch input from some area (say, virtual keyboard) to go to the enclave. The rest of what it does is pretty meaningless, given these constraints.
I wasn't referencing Apple's Secure Enclave - I'm just using the new buzzword for "trusted computing"/trusted execution. Such at this thesis from Cal a couple years ago [0]
> However, FPGAs can be way more secure than any kind of ASICs
I agree with you! The issue is usability (and I guess it depends use case to use case). We gotta navigate a happy path between security and usability. Otherwise users will try to undermine security features.
This is an interesting convo tho. I'm going to favorite this for some thinking later.
> Why resort down to ad personam (the last two paragraphs)? These are not insults, but not valid arguments, either
That wasn't meant to be an ad personam, and if it was I apologize. It's literally was advice I'd give anyone who's worried.
[0] - https://www2.eecs.berkeley.edu/Pubs/TechRpts/2021/EECS-2021-...