6 ms·

For a local workstation user not doing anything sensitive etc I don’t see why you wouldn’t do this. Be smart. Be clean online. And enjoy the full power of your

For a local workstation user not doing anything sensitive etc I don’t see why you wouldn’t do this. Be smart. Be clean online. And enjoy the full power of your box. A server though, especially one that will be targeted, should take the performance hit and get patched.

twic 7y ago
Isn't it the other way round? Most of these mitigations are to stop hostile code from stealing your secrets. A physical server doesn't run hostile code. A workstation with a web browser which supports JavaScript runs potentially hostile code all day, every day.
- vbezhenar 7y ago
  Depends on your browsing pattern. I don't visit random websites often. And even if I do, I don't stick there for long (those exploits need a lot of time to extract useful data). And sites that I visit are trusted (like HN) so they are very unlikely to run exploits.
  - arghwhat 7y ago
    You run arbitrary code from a lot more sites than you just those you visit, and I doubt you're combing through it. Third-party JS, tracking, unblocked advertisements, possibly malicious on-site code, etc. If you're allowing any site to run JavaScript, you're running entirely arbitrary and uncontrolled code on your machine, and thus is in dire need of the mitigations. It's a different situation for a server designed to not run remote code, which makes it practically impossible to exploit speculative execution vulnerabilities.
    - deleted 7y ago
      [deleted]
  - dijit 7y ago
    Sorry, I consider this to be a very poor defence. You might trust the site you go to; but that's not all the javascript that gets loaded, there are includes that a lot of web developers will use for convenience, there are ad networks and there are bugs that could allow some unintended javascript to get loaded (like with bit-squatting[0]). It's not a given that you're safe running javascript if you only visit sites you trust. Even if you are INCREDIBLY sanitary, which I would argue is unrealistic (just check your history and you'll see that you probably visit many sites off of a google search). [0]: http://www.youtube.com/watch?v=lZ8s1JwtNas http://www.youtube.com/watch?v=lZ8s1JwtNas / http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html
- deleted 7y ago
  [deleted]
- badsectoracula 7y ago
  Some random server you have control over most likely doesn't run much hostile stuff. But nowadays a HUGE number of "servers" are really cloud-hosted VMs and on those every single thing is hostile from the cloud company's perspective.
  - twic 7y ago
    True - i did write physical on purpose!
    - badsectoracula 7y ago
      But the machines hosting those VMs are physical servers too and i'm certain than gigatexal was including them when he wrote that comment.
vrodic 7y ago
If you don't run untrusted code you should be fine on bare metal servers too.
- equalunique 7y ago
  These days I find it hard to trust the many dependencies installed by language-level package managers. OS-level system package managers tend to do better, but they too have also had incidents.
  - geofft 7y ago
    Then why do you have them installed? Surely you're not using those dependencies you don't trust as actual dependencies of your server application, are you?
    - a1369209993 7y ago
      Fraudulent transitive dependencies. My application depends on libuseful version 1 or later. libuseful_1 depends on libtiny, but libuseful_2 depends on libbigballofmud, which consists of libtiny and 800 other libraries that have been merged together for political reasons. libuseless, which was also merged into libbigballofmud, depends on rce-daemon, or nvidia-brick-the-install, or systemd, and I've never heard of rce-daemon before, so it's not blacklisted and installs with no error message. As the other two options suggest, this is not hypothetical.
      - majewsky 7y ago
        > nvidia-brick-the-install Is this in reference to when the nvidia driver had sudo rm -rf /usr /lib/something/something in its install script?
        a1369209993 7y ago
        ... I'm not actually surprised. But no; my desktop machine has a video card that doesn't display anything (black screen) if booted with the non-legacy nvidia drivers. I had to boot off a old 32-bit install to get rid of them and then wrestle apt/dpkg back into a sane state.
melvinroest 7y ago
I didn’t read the article, but I would advice against the idea that I can read a good chunk of your memory with Meltdown and Spectre via a JS ad. I am fuzzy on the details, but I do think it’s possible. Meltdown is out of order execution detectable from caches. They made it difficult to get a good timing source in JS, so there’s that. Spectre is training the branch predictor unit to execute code that you want in caches. You would need a good timing source again. So there is some security in place. I think a creative hacker will get around it though.
- roblabla 7y ago
  > They made it difficult to get a good timing source in JS, so there’s that. No, they didn't. A while loop with a counter is a good timing source, and you can't really prevent that without severely crippling everything's performance. Want a good timing source in your browser? Just follow those three easy steps: 1. Start a while loop in a webworker 2. In that while loop, incrementing a counter in a SharedArrayBuffer 3. In the main javascript, read that number from the SharedArrayBuffer. Bam, a decent clock.
  - deleted 7y ago
    [deleted]
  - Filligree 7y ago
    Didn't they disable SharedArraybuffer for that reason?
    - striking 7y ago
      Yes and no? > Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome [re-enabled it in v67](https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270) on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities. from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

twic 7y ago

Isn't it the other way round? Most of these mitigations are to stop hostile code from stealing your secrets. A physical server doesn't run hostile code. A workstation with a web browser which supports JavaScript runs potentially hostile code all day, every day.

vbezhenar 7y ago
Depends on your browsing pattern. I don't visit random websites often. And even if I do, I don't stick there for long (those exploits need a lot of time to extract useful data). And sites that I visit are trusted (like HN) so they are very unlikely to run exploits.
- arghwhat 7y ago
  You run arbitrary code from a lot more sites than you just those you visit, and I doubt you're combing through it. Third-party JS, tracking, unblocked advertisements, possibly malicious on-site code, etc. If you're allowing any site to run JavaScript, you're running entirely arbitrary and uncontrolled code on your machine, and thus is in dire need of the mitigations. It's a different situation for a server designed to not run remote code, which makes it practically impossible to exploit speculative execution vulnerabilities.
  - deleted 7y ago
    [deleted]
- dijit 7y ago
  Sorry, I consider this to be a very poor defence. You might trust the site you go to; but that's not all the javascript that gets loaded, there are includes that a lot of web developers will use for convenience, there are ad networks and there are bugs that could allow some unintended javascript to get loaded (like with bit-squatting[0]). It's not a given that you're safe running javascript if you only visit sites you trust. Even if you are INCREDIBLY sanitary, which I would argue is unrealistic (just check your history and you'll see that you probably visit many sites off of a google search). [0]: http://www.youtube.com/watch?v=lZ8s1JwtNas http://www.youtube.com/watch?v=lZ8s1JwtNas / http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html
deleted 7y ago
[deleted]
badsectoracula 7y ago
Some random server you have control over most likely doesn't run much hostile stuff. But nowadays a HUGE number of "servers" are really cloud-hosted VMs and on those every single thing is hostile from the cloud company's perspective.
- twic 7y ago
  True - i did write physical on purpose!
  - badsectoracula 7y ago
    But the machines hosting those VMs are physical servers too and i'm certain than gigatexal was including them when he wrote that comment.

vrodic 7y ago

If you don't run untrusted code you should be fine on bare metal servers too.

equalunique 7y ago
These days I find it hard to trust the many dependencies installed by language-level package managers. OS-level system package managers tend to do better, but they too have also had incidents.
- geofft 7y ago
  Then why do you have them installed? Surely you're not using those dependencies you don't trust as actual dependencies of your server application, are you?
  - a1369209993 7y ago
    Fraudulent transitive dependencies. My application depends on libuseful version 1 or later. libuseful_1 depends on libtiny, but libuseful_2 depends on libbigballofmud, which consists of libtiny and 800 other libraries that have been merged together for political reasons. libuseless, which was also merged into libbigballofmud, depends on rce-daemon, or nvidia-brick-the-install, or systemd, and I've never heard of rce-daemon before, so it's not blacklisted and installs with no error message. As the other two options suggest, this is not hypothetical.
    - majewsky 7y ago
      > nvidia-brick-the-install Is this in reference to when the nvidia driver had sudo rm -rf /usr /lib/something/something in its install script?
      - a1369209993 7y ago
        ... I'm not actually surprised. But no; my desktop machine has a video card that doesn't display anything (black screen) if booted with the non-legacy nvidia drivers. I had to boot off a old 32-bit install to get rid of them and then wrestle apt/dpkg back into a sane state.

melvinroest 7y ago

I didn’t read the article, but I would advice against the idea that I can read a good chunk of your memory with Meltdown and Spectre via a JS ad. I am fuzzy on the details, but I do think it’s possible. Meltdown is out of order execution detectable from caches. They made it difficult to get a good timing source in JS, so there’s that. Spectre is training the branch predictor unit to execute code that you want in caches. You would need a good timing source again. So there is some security in place. I think a creative hacker will get around it though.

roblabla 7y ago
> They made it difficult to get a good timing source in JS, so there’s that. No, they didn't. A while loop with a counter is a good timing source, and you can't really prevent that without severely crippling everything's performance. Want a good timing source in your browser? Just follow those three easy steps: 1. Start a while loop in a webworker 2. In that while loop, incrementing a counter in a SharedArrayBuffer 3. In the main javascript, read that number from the SharedArrayBuffer. Bam, a decent clock.
- deleted 7y ago
  [deleted]
- Filligree 7y ago
  Didn't they disable SharedArraybuffer for that reason?
  - striking 7y ago
    Yes and no? > Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome [re-enabled it in v67](https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270) on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities. from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...