7 ms·

> Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the wa

> Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary. lol, javascript

xref 8y ago
but the sandboxes, think of the inescapable sandboxes!
kbenson 8y ago
"Many customers" meaning people and orgs running server software on direct hardware. Does your caching or database server run user provided code? Is it accessible to the outside in any way? If not, then maybe it doesn't need the patch.
- deleted 8y ago
  [deleted]
- infinity0 8y ago
  The article says "Many computer users" not "Many customers". Furthermore when the article mentions "customers" elsewhere we can probably assume it means "Intel customers" which is a much greater subset than the group you're talking about, and which would be probably less than 1% as numerous as the "Many computer users" that run javascript. lol, javascript
  - kbenson 8y ago
    > which would be probably less than 1% as numerous as the "Many computer users" that run javascript. So? Many does not mean most. There's a choice to be made, apply the security patch and accept the performance loss, or don't. Some people may not need to to remain close to as safe as they were previously based on their configuration for some of their systems, and I would guess the number of systems easily numbers in the millions. This is a benefit for those people, and worth mentioning, even if it's not nearly a large a number as the total number of CPUs or customers.
    - infinity0 8y ago
      In this case, many does mean most.
- cosmojg 8y ago
  https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...
  - kbenson 8y ago
    Are you trying to imply that because somehow ASLR can't protect you and they show and example in the context of Javascript that somehow that means your Postgres server/service is immediately at risk? At least, that's all I can think you are trying to imply, because you didn't actually say anything, you just dropped a link. It's hard to have a useful conversation when that happens.
blauditore 8y ago
Have timing attacks been done successfully in JS? I imagine it's much harder since you have much less low-level control and the engine might impose too much noise. However, wasm is a different story.
- infinity0 8y ago
  web search "spy in the sandbox"
- extrapickles 8y ago
  Yes, Someone did an ASLR bypass in JavaScript, and a key component was being able to measure time accurately. https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...
- josefx 8y ago
  I think browsers currently have to limit the precision of their built-in timer APIs and they had to kill shared mutable state support for their thread APIs so attackers couldn't implement their own.
theprotocol 8y ago
>Another issue is whether the customer should install the fix at all Microsoft will surely decide for me on my Windows 10 gaming PC. Better save my work (which I sometimes do even on a gaming machine) frequently lest the masters deem it fit to restart while I'm away having lunch if they decide I can live with the performance hit.
- hanselot 8y ago
  It sounds a lot like you are blaming someone else for not having control of your computer.
- deleted 8y ago
  [deleted]
- chrisper 8y ago
  Just mark every 2nd Tuesday of a month as patch day and you won't have surprises!
  - theprotocol 8y ago
    • Updates are not served to me at regular, known intervals. Perhaps it's due to a progressive rollout policy of some kind. • Certain days come up that I, the paying user, do not want to patch on. Microsoft wins this disagreement and I lose. This occurs in a glib fashion with a message like "Hey, just a heads up, we are going to restart your computer" (whether I like it or not). It is my computer, there is no "we!" It will absolutely close programs with unsaved work if I am not there. • Maybe I don't want the performance hit on my gaming PC. This is another element of surprise: who knows how bad it'll be? Certainly not the users if Intel and Microsoft have their way. • Yet another element of surprise: I've had hardware stop working after updates. I cannot wait until it becomes viable to escape the toxicity of companies such as Intel and Microsoft.
    - harry8 8y ago
      You are best placed to make that assessment on your own needs. Know that many of us have done it and it turned out to be easier than we thought it would be. Good luck with the analysis!
shawn-butler 8y ago
My opinion of Bruce Perens just decreased markedly. Hopefully he will edit this blog post with better advice to the "casual" computer user.

xref 8y ago

but the sandboxes, think of the inescapable sandboxes!

kbenson 8y ago

"Many customers" meaning people and orgs running server software on direct hardware. Does your caching or database server run user provided code? Is it accessible to the outside in any way? If not, then maybe it doesn't need the patch.

deleted 8y ago
[deleted]
infinity0 8y ago
The article says "Many computer users" not "Many customers". Furthermore when the article mentions "customers" elsewhere we can probably assume it means "Intel customers" which is a much greater subset than the group you're talking about, and which would be probably less than 1% as numerous as the "Many computer users" that run javascript. lol, javascript
- kbenson 8y ago
  > which would be probably less than 1% as numerous as the "Many computer users" that run javascript. So? Many does not mean most. There's a choice to be made, apply the security patch and accept the performance loss, or don't. Some people may not need to to remain close to as safe as they were previously based on their configuration for some of their systems, and I would guess the number of systems easily numbers in the millions. This is a benefit for those people, and worth mentioning, even if it's not nearly a large a number as the total number of CPUs or customers.
  - infinity0 8y ago
    In this case, many does mean most.
cosmojg 8y ago
https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...
- kbenson 8y ago
  Are you trying to imply that because somehow ASLR can't protect you and they show and example in the context of Javascript that somehow that means your Postgres server/service is immediately at risk? At least, that's all I can think you are trying to imply, because you didn't actually say anything, you just dropped a link. It's hard to have a useful conversation when that happens.

blauditore 8y ago

Have timing attacks been done successfully in JS? I imagine it's much harder since you have much less low-level control and the engine might impose too much noise. However, wasm is a different story.

infinity0 8y ago
web search "spy in the sandbox"
extrapickles 8y ago
Yes, Someone did an ASLR bypass in JavaScript, and a key component was being able to measure time accurately. https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...
josefx 8y ago
I think browsers currently have to limit the precision of their built-in timer APIs and they had to kill shared mutable state support for their thread APIs so attackers couldn't implement their own.

theprotocol 8y ago

>Another issue is whether the customer should install the fix at all Microsoft will surely decide for me on my Windows 10 gaming PC. Better save my work (which I sometimes do even on a gaming machine) frequently lest the masters deem it fit to restart while I'm away having lunch if they decide I can live with the performance hit.

hanselot 8y ago
It sounds a lot like you are blaming someone else for not having control of your computer.
deleted 8y ago
[deleted]
chrisper 8y ago
Just mark every 2nd Tuesday of a month as patch day and you won't have surprises!
- theprotocol 8y ago
  • Updates are not served to me at regular, known intervals. Perhaps it's due to a progressive rollout policy of some kind. • Certain days come up that I, the paying user, do not want to patch on. Microsoft wins this disagreement and I lose. This occurs in a glib fashion with a message like "Hey, just a heads up, we are going to restart your computer" (whether I like it or not). It is my computer, there is no "we!" It will absolutely close programs with unsaved work if I am not there. • Maybe I don't want the performance hit on my gaming PC. This is another element of surprise: who knows how bad it'll be? Certainly not the users if Intel and Microsoft have their way. • Yet another element of surprise: I've had hardware stop working after updates. I cannot wait until it becomes viable to escape the toxicity of companies such as Intel and Microsoft.
  - harry8 8y ago
    You are best placed to make that assessment on your own needs. Know that many of us have done it and it turned out to be easier than we thought it would be. Good luck with the analysis!

shawn-butler 8y ago

My opinion of Bruce Perens just decreased markedly. Hopefully he will edit this blog post with better advice to the "casual" computer user.