4 ms·

While I agree with this premise, taking an extreme view, practically all software which users routinely update are vulnerable to the first party / author being

While I agree with this premise, taking an extreme view, practically all software which users routinely update are vulnerable to the first party / author being compelled to ship a harmful release. The lack of a distribution trust model for the web has long bummed me out, but even snake oil E2EE is a good thing because it makes an active (and potentially detectable) intervention necessary to exploit a client. Supply chain attacks remain a huge mess. Unless you can validate the worthiness and authenticity of an update, or sandbox it sufficiently, most software can become a threat. A more manual, opt-in update process for web apps (via service workers) would be a nice innovation, but I doubt it would provide much more safety to non technical end users, since the harder question is whether a particular update is harmful. Solving that verification problem is the crux of the issue regardless of how rapidly software updates.

goodpoint 3y ago
> Unless you can validate the worthiness and authenticity of an update That's the job of traditional Linux distros. > or sandbox it sufficiently That does nothing when it comes to E2EE.
- chromakode 3y ago
  > That's the job of traditional Linux distros. I share this view, but I also think it's very difficult to verify such validation is happening. I don't think most end users would want a distro stable enough to meet a high review bar. > That does nothing when it comes to E2EE Not all components need access to the keys or user data. Reducing attack surface reduces the amount that needs to be validated.
croes 3y ago
One step further, every software you didn't compile yourself and checked the source could have a secret trigger to do harm. And you need to trust the compiler.
- bhawks 3y ago
  You trust that CPU doing the build? Have you heard about the mess Intel Management Engine is? Unless you build from the transistors up you have incoherent security theater.
  - rootw0rm 3y ago
    hold on, which universe did you source your matter from?
  - BasedAnon 3y ago
    Here's a tutorial if you want to actually do this, although it's worth pointing out that quality is heavily dependent on how much you're willing to shell out for equipment: https://www.youtube.com/watch?v=s1MCi7FliVY https://www.youtube.com/watch?v=s1MCi7FliVY
- wolletd 3y ago
  https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/
  - duck2 3y ago
    Nothing old silicon and analog peripherals can't solve.
- EGreg 3y ago
  https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- Koffiepoeder 3y ago
  Indeed, in the end it all comes down to trust. One of my favourite HN comments of all time is this one: https://news.ycombinator.com/item?id=33899478 https://news.ycombinator.com/item?id=33899478 If you want to be 'really' secure, you can trust noone. No silicon, no software, no compilers, no certificates, no power grids, no networks, no friends, no coworkers, no nothing. But that is no life I'd want to live. So I pick my battles and make sure my SecOps is better than 99.9% of the people out there. For me that suffices. YMMV.
EGreg 3y ago
Now AI shows just how much malware is in our package managers: https://twitter.com/engageusersai/status/1672872723486310400?s=46&t=AFVvlb12qQVAdcGldyNTZw https://twitter.com/engageusersai/status/1672872723486310400...
upofadown 3y ago
If it works out that the first party has to ship a harmful release to everyone and they can only supply that release through a second party in source code form then we are way ahead of the case where there is only one party. A conspiracy involving multiple entities is much harder to get away with than a unilateral action.
NoZebra120vClip 3y ago
Currently, following the latest updates are a Sophie's choice. Because if your software is a month old, it may have one or two known vulnerabilities, which may or may not be disclosed, may or may not have a POC, and may or may not be actively exploited in the wild. But if you download and install the latest update, then you may receive mitigations for known exploits, but now you very likely have an unknown number of new zero-day vulnerabilities. So update decisions could have a calculus like, "it's already working; I don't need any feature updates; I'll stick with the stable version" and then attempting to evaluate each CVE on its merits vs. the mitigations offered in each update. (Of course, the way developers like KeePassXC are fighting with the NVD shows that CVE descriptions can't even be trusted these days.) I foolishly disabled automatic updates for my consumer-grade WiFi router, and I didn't have a plan for manual updates, so it got pwned. I read a few CVEs and I'm fairly sure I know how it was pwned remotely. Thankfully it didn't seem to be making lateral moves into my computing devices, or acting against me personally, and I was able to disinfect the router and put it back into service. The vulnerabilities that enabled the pwnage were fixed by an update which was released about a month before the pwnage, so if I'd been on automatic updates, I probably would've been safe. And that's what the hackers count on.
- predictabl3 3y ago
  I'm sorry this makes absolutely no sense to me. It feels like a convoluted explanation for being stubborn about auto updates and then an example of precisely why they're useful. I would take an unaudited patched-for-known-cves over just not updating any day.

goodpoint 3y ago

> Unless you can validate the worthiness and authenticity of an update That's the job of traditional Linux distros. > or sandbox it sufficiently That does nothing when it comes to E2EE.

chromakode 3y ago
> That's the job of traditional Linux distros. I share this view, but I also think it's very difficult to verify such validation is happening. I don't think most end users would want a distro stable enough to meet a high review bar. > That does nothing when it comes to E2EE Not all components need access to the keys or user data. Reducing attack surface reduces the amount that needs to be validated.

croes 3y ago

One step further, every software you didn't compile yourself and checked the source could have a secret trigger to do harm. And you need to trust the compiler.

bhawks 3y ago
You trust that CPU doing the build? Have you heard about the mess Intel Management Engine is? Unless you build from the transistors up you have incoherent security theater.
- rootw0rm 3y ago
  hold on, which universe did you source your matter from?
- BasedAnon 3y ago
  Here's a tutorial if you want to actually do this, although it's worth pointing out that quality is heavily dependent on how much you're willing to shell out for equipment: https://www.youtube.com/watch?v=s1MCi7FliVY https://www.youtube.com/watch?v=s1MCi7FliVY
wolletd 3y ago
https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/
- duck2 3y ago
  Nothing old silicon and analog peripherals can't solve.
EGreg 3y ago
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
Koffiepoeder 3y ago
Indeed, in the end it all comes down to trust. One of my favourite HN comments of all time is this one: https://news.ycombinator.com/item?id=33899478 https://news.ycombinator.com/item?id=33899478 If you want to be 'really' secure, you can trust noone. No silicon, no software, no compilers, no certificates, no power grids, no networks, no friends, no coworkers, no nothing. But that is no life I'd want to live. So I pick my battles and make sure my SecOps is better than 99.9% of the people out there. For me that suffices. YMMV.

EGreg 3y ago

Now AI shows just how much malware is in our package managers: https://twitter.com/engageusersai/status/1672872723486310400?s=46&t=AFVvlb12qQVAdcGldyNTZw https://twitter.com/engageusersai/status/1672872723486310400...

upofadown 3y ago

If it works out that the first party has to ship a harmful release to everyone and they can only supply that release through a second party in source code form then we are way ahead of the case where there is only one party. A conspiracy involving multiple entities is much harder to get away with than a unilateral action.

NoZebra120vClip 3y ago

Currently, following the latest updates are a Sophie's choice. Because if your software is a month old, it may have one or two known vulnerabilities, which may or may not be disclosed, may or may not have a POC, and may or may not be actively exploited in the wild. But if you download and install the latest update, then you may receive mitigations for known exploits, but now you very likely have an unknown number of new zero-day vulnerabilities. So update decisions could have a calculus like, "it's already working; I don't need any feature updates; I'll stick with the stable version" and then attempting to evaluate each CVE on its merits vs. the mitigations offered in each update. (Of course, the way developers like KeePassXC are fighting with the NVD shows that CVE descriptions can't even be trusted these days.) I foolishly disabled automatic updates for my consumer-grade WiFi router, and I didn't have a plan for manual updates, so it got pwned. I read a few CVEs and I'm fairly sure I know how it was pwned remotely. Thankfully it didn't seem to be making lateral moves into my computing devices, or acting against me personally, and I was able to disinfect the router and put it back into service. The vulnerabilities that enabled the pwnage were fixed by an update which was released about a month before the pwnage, so if I'd been on automatic updates, I probably would've been safe. And that's what the hackers count on.

predictabl3 3y ago
I'm sorry this makes absolutely no sense to me. It feels like a convoluted explanation for being stubborn about auto updates and then an example of precisely why they're useful. I would take an unaudited patched-for-known-cves over just not updating any day.