[alephnerd]

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.

[greenish_shores]

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?

[alephnerd]

> 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.

[greenish_shores]

> 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.

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.

[alephnerd]

> 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

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)

[greenish_shores]

Why resort down to ad personam (the last two paragraphs)? These are not insults, but not valid arguments, either.

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.

[alephnerd]

Ah! I think our wires got crossed!

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-...