3 ms·

> Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this w

by flukus 9y ago

> Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this whole debacle. Except for that whole web thing that has most of the world running untrusted code just about every minute of every day. Security hygiene doesn't protect you from this.

userbinator 9y ago
Except for that whole web thing that has most of the world running untrusted code just about every minute of every day Certainly those who e.g. have JS off by default are currently in the minority, but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Things like TEMPEST[1] have shown for many years that side-channel attacks are extremely difficult to defend against, even for an attacker who is merely in proximity to the hardware and can't influence it at all; nevermind running code directly on it. It was only a matter of time. A lot of malware researchers already don't trust VMs and use separate physical hardware, precisely because of these risks of sharing trusted and untrusted code on the same hardware. [1] https://en.wikipedia.org/wiki/TEMPEST https://en.wikipedia.org/wiki/TEMPEST
- adjkant 9y ago
  > but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Your average user: Javascript is on the website not on my computer so it's fine.
  - continuational 9y ago
    Such users simply expect the computer they bought to work as advertised. Is it really their fault when it can’t run a browser correctly?
  - robin_reala 9y ago
    Your average user: what’s a Javascript?
- continuational 9y ago
  There’s not a single program that i trust. Not even the programs I’ve written myself; even taken all reasonable precautions, it’s far too easy to introduce a vulnerability. There are programs that I choose to run with escalated privileges, like the operating system, out of necessity. If I can’t run untrusted code; I simply can’t compute. It’s the main thing hardware is designed to do.
  - andrewem 9y ago
    For instance, even if you read your compiler's source code and then compile it, there's no way to know that the compilation process didn't insert a back door, as in this classic essay: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
  - bmm6o 9y ago
    I'm not saying you're wrong, but you seem to be using a different definition of untrusted than the rest of the thread. Your code may not be perfect, but you certainly don't suspect it's launching a timing attack against your machine's kernel, and exfiltrating what it discovers, right?
- leoc 9y ago
  Sorry, but no way. Local execution of sandboxed or VMed code isn't going away, and shouldn't go away, and suggesting that it should or will is honestly a bit deformation professionnelle, not to say a tiny bit crackers. Neither Spectre nor several more Spectres will change that. Computing mostly got along fine without sandboxing in the 'Seventies, but it could do so because computing in the 'Seventies was a radically different world for many other reasons too. We need more, and more reliable, sandboxing not less. If that means that, for instance, hardware manufacturers have to start getting serious about relative timing guarantees instead of cheerfully doing whatever it takes to beat the benchmarks, well Too Bad Really. It's a direction that things should probably have been going in anyway in the interests of real-time perfomance guarantees.
  - nine_k 9y ago
    IBM offered VM-level sandboxing back then, starting from s/370 hardware in 1972. https://en.wikipedia.org/wiki/VM_(operating_system) https://en.wikipedia.org/wiki/VM_(operating_system)
greggman 9y ago
while not directly related to meltdown and Spectre it's not just the web. Almost all code really shoud be considered untrusted. Every game on steam. every app on the app store. many apps use ad or analytics libraries the app devs don't know the innards of. there are plenty of apps that are just skinned web browsers effectively downloading new code all the time and while I might trust Facebook or maybe Slack to check all the 3rd party libraries and updates they import I doubt your average app dev team does any of that.

by flukus 9y ago

userbinator 9y ago

Except for that whole web thing that has most of the world running untrusted code just about every minute of every day Certainly those who e.g. have JS off by default are currently in the minority, but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Things like TEMPEST[1] have shown for many years that side-channel attacks are extremely difficult to defend against, even for an attacker who is merely in proximity to the hardware and can't influence it at all; nevermind running code directly on it. It was only a matter of time. A lot of malware researchers already don't trust VMs and use separate physical hardware, precisely because of these risks of sharing trusted and untrusted code on the same hardware. [1] https://en.wikipedia.org/wiki/TEMPEST https://en.wikipedia.org/wiki/TEMPEST

adjkant 9y ago
> but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Your average user: Javascript is on the website not on my computer so it's fine.
- continuational 9y ago
  Such users simply expect the computer they bought to work as advertised. Is it really their fault when it can’t run a browser correctly?
- robin_reala 9y ago
  Your average user: what’s a Javascript?
continuational 9y ago
There’s not a single program that i trust. Not even the programs I’ve written myself; even taken all reasonable precautions, it’s far too easy to introduce a vulnerability. There are programs that I choose to run with escalated privileges, like the operating system, out of necessity. If I can’t run untrusted code; I simply can’t compute. It’s the main thing hardware is designed to do.
- andrewem 9y ago
  For instance, even if you read your compiler's source code and then compile it, there's no way to know that the compilation process didn't insert a back door, as in this classic essay: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
- bmm6o 9y ago
  I'm not saying you're wrong, but you seem to be using a different definition of untrusted than the rest of the thread. Your code may not be perfect, but you certainly don't suspect it's launching a timing attack against your machine's kernel, and exfiltrating what it discovers, right?
leoc 9y ago
Sorry, but no way. Local execution of sandboxed or VMed code isn't going away, and shouldn't go away, and suggesting that it should or will is honestly a bit deformation professionnelle, not to say a tiny bit crackers. Neither Spectre nor several more Spectres will change that. Computing mostly got along fine without sandboxing in the 'Seventies, but it could do so because computing in the 'Seventies was a radically different world for many other reasons too. We need more, and more reliable, sandboxing not less. If that means that, for instance, hardware manufacturers have to start getting serious about relative timing guarantees instead of cheerfully doing whatever it takes to beat the benchmarks, well Too Bad Really. It's a direction that things should probably have been going in anyway in the interests of real-time perfomance guarantees.
- nine_k 9y ago
  IBM offered VM-level sandboxing back then, starting from s/370 hardware in 1972. https://en.wikipedia.org/wiki/VM_(operating_system) https://en.wikipedia.org/wiki/VM_(operating_system)

greggman 9y ago

while not directly related to meltdown and Spectre it's not just the web. Almost all code really shoud be considered untrusted. Every game on steam. every app on the app store. many apps use ad or analytics libraries the app devs don't know the innards of. there are plenty of apps that are just skinned web browsers effectively downloading new code all the time and while I might trust Facebook or maybe Slack to check all the 3rd party libraries and updates they import I doubt your average app dev team does any of that.