Hacker News new | ask | show | jobs
by servus45678981 749 days ago
Then I am switching to a feature phone Nokia by HMD
2 comments

> feature phone Nokia by HMD

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)

Check out postmarketOS. Can run on a Nokia you're specifying, but not only :)
Equally open to vulnerabilities. For example, there's an unpatched GLIBC vulnerability in Alpine Linux (which is the distro postmarket is built on).
CVE-2015-0235? What the hell? -2015- and still unpatched? But apparently it looks like the case.

Anyway, Alpine seem to use musl instead of glibc.

Packages will still call and use GLIBC - especially those that are cross-platform, because migrating your codebase to support a new ABI is a PITA.

This is a classic example I use when explaining the need for SBOMs and Software Supply Chain Security to non-software C-suite.

Do you have any info why this CVE is still unpatched? It seems absolutely crazy, given it is known (of course, a lot of 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 - given this was in (g)libc, even Linux namespaces would've potentially resisted most of things which can be done with it. Not to mention light hypervisors with very minimalistic codebase like Xen.

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?

> Do you have any info why this CVE is still unpatched

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.