4 ms·

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also ru

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot. It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed. A school teacher wearing a condom is strictly speaking safer than the alternative, and yet someone should still be fired.

Syonyk 4y ago
> If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them. But remember, L1TF/Foreshadow could reach across virtual machine boundaries. It's not just inter-process speculation that's a problem.
- nickelpro 4y ago
  Yep, and yet everyone in this thread seems to be rushing to kneecap their own performance, for what? My laptop isn't a GKE node. There's a reason this CVE is classified as medium severity
  - CamperBob2 4y ago
    I think the one-dimensional severity classification is part of the problem. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry. Probably 90% of PCs are single-user Windows desktops, though. It's a "nonexistent severity" issue for those use cases... yet we all get to pay.
    - nickelpro 4y ago
      Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time" But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time?
      - Syonyk 4y ago
        > But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time? It's... hard. A lot of the "constant cache behavior" and "constant time behavior" algorithms were written back in the day when the CPU speeds didn't change randomly on you, or at worst toggled between "idle" and "running hard." Think... oh, even the Core 2 days, really. They didn't switch that fast. And then the hardware behavior changed out from under the algorithms, and nobody noticed. Now the throttling is far more rapid. So they may still be "constant instruction count," but that no longer implies constant time. It's... complicated. :( And what's worse, even the people in charge of managing the complexity don't understand all the details anymore. When stuff like this surprises Intel, we've got problems.
        nickelpro 4y ago
        Sure, but you can just check the high precision wall-clock timer at the end of your computation and makes sure you took at least X nanoseconds, and pad that out so that X is always greater than the amount of wall-clock nanoseconds the actual computation takes. Then, following a computation, you sleep until X. While this won't fool timing attacks that are operating on the same machine as your process, the computation time becomes completely opaque to the network which is what the "remote" attacks are built on.
ziddoap 4y ago
Not all timing attacks require any sort of privileged access. As one example, OpenSSH had a timing attack where under certain configurations a query for a non-existent user returned faster than an existing user, allowing attackers to enumerate user accounts. I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you think it's all theatre is naive. Weighing each exploit against your attack surface, risks, and risk tolerance is not. >It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed. Blaming researchers for security theatre when it is the organizations which are not doing their due diligence is, at least to me, a weird way to look at things.
- nickelpro 4y ago
  I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance impact on personal computers. These side-channel bugs are minor annoyances, and mostly a problem for cloud providers. I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just because their unsafe in specific application spaces, which seems to be what half of HN starts advocating for whenever this stuff comes up. An application bug like OpenSSH is a completely separate spiritually from the hardware bugs that inspire these mitigation discussions.
  - ziddoap 4y ago
    I agree on almost all fronts. The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.
  - 4y ago

Syonyk 4y ago

> If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them. But remember, L1TF/Foreshadow could reach across virtual machine boundaries. It's not just inter-process speculation that's a problem.

nickelpro 4y ago
Yep, and yet everyone in this thread seems to be rushing to kneecap their own performance, for what? My laptop isn't a GKE node. There's a reason this CVE is classified as medium severity
- CamperBob2 4y ago
  I think the one-dimensional severity classification is part of the problem. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry. Probably 90% of PCs are single-user Windows desktops, though. It's a "nonexistent severity" issue for those use cases... yet we all get to pay.
  - nickelpro 4y ago
    Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time" But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time?
    - Syonyk 4y ago
      > But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time? It's... hard. A lot of the "constant cache behavior" and "constant time behavior" algorithms were written back in the day when the CPU speeds didn't change randomly on you, or at worst toggled between "idle" and "running hard." Think... oh, even the Core 2 days, really. They didn't switch that fast. And then the hardware behavior changed out from under the algorithms, and nobody noticed. Now the throttling is far more rapid. So they may still be "constant instruction count," but that no longer implies constant time. It's... complicated. :( And what's worse, even the people in charge of managing the complexity don't understand all the details anymore. When stuff like this surprises Intel, we've got problems.
      - nickelpro 4y ago
        Sure, but you can just check the high precision wall-clock timer at the end of your computation and makes sure you took at least X nanoseconds, and pad that out so that X is always greater than the amount of wall-clock nanoseconds the actual computation takes. Then, following a computation, you sleep until X. While this won't fool timing attacks that are operating on the same machine as your process, the computation time becomes completely opaque to the network which is what the "remote" attacks are built on.

ziddoap 4y ago

Not all timing attacks require any sort of privileged access. As one example, OpenSSH had a timing attack where under certain configurations a query for a non-existent user returned faster than an existing user, allowing attackers to enumerate user accounts. I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you think it's all theatre is naive. Weighing each exploit against your attack surface, risks, and risk tolerance is not. >It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed. Blaming researchers for security theatre when it is the organizations which are not doing their due diligence is, at least to me, a weird way to look at things.

nickelpro 4y ago
I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance impact on personal computers. These side-channel bugs are minor annoyances, and mostly a problem for cloud providers. I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just because their unsafe in specific application spaces, which seems to be what half of HN starts advocating for whenever this stuff comes up. An application bug like OpenSSH is a completely separate spiritually from the hardware bugs that inspire these mitigation discussions.
- ziddoap 4y ago
  I agree on almost all fronts. The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.
- 4y ago