6 ms·

Deal with them on OS/VM/sandbox/"system" level. Treat time measurement as privileged. Make it really hard to get precise enough timing in untrusted processes.

Deal with them on OS/VM/sandbox/"system" level. Treat time measurement as privileged. Make it really hard to get precise enough timing in untrusted processes. Disable TSC access, lower clock_gettime precision, make clock_gettime return fuzzy (randomized) time. Randomize CPU frequency to make usage of spinning threads for time measurement hard. Insert randomized delays into untrusted binaries, kinda like DTrace inserts probes (i.e. imagine a JavaScript JIT that inserts no-ops all over the compiled code, and randomly changes these to random sleeps). etc.

jjuhl 9y ago
But those are all just mitigations, not fixes. Such changes don't guarantee that it's impossible to still leak information - just that it will be harder (but not inherently impossible) to exploit.
- nine_k 9y ago
  If you increase the number of bits in a hash, you do not guarantee against collisions, but you can make them so infrequent that searching for them becomes impractical. If the randomizations have such an effect that data sniffing is still possible but its speed is 1 bit per week, trying to sniff something interesting becomes impractical. (Or not; depends on your threat model.)
- heiei98jejrj282 9y ago
  Yes they are just mitigations. What else you got? Firewalls aren’t iron clad they just minimize who can get in There will always be deep, broadly unseen problems; it’s an information availability problem, not a technical one... testing won’t catch some clever edge case a random hacker can come up with because Intel, etc, have to ship, and they ship a design they can produce with information at hand; new deficiencies will be found And those of us in no position to make chips have to suck that up and accept mitigation’s So far no one has come up with a perfect model for any task that requires many layers of context and abstractions; physics, medicine... they’re all racing to find the next blocker and move on. Same with chip makers IMO what needs changing is economics. Information is being hidden and not for security but to protect business models. The economy could have been hit hard if this was known sooner. And having an economy hingeing on that truth, that theres a bug that could disrupt it we just haven’t found it yet, is economic stability and security through obscurity.
- voidmain 9y ago
  The root of all evil is nondeterminism. A program which executes deterministically cannot receive a timing channel! So "all" we have to do to end this entire class of problems is deny all nondeterministic features, including shared memory threading and timers and two way network communication, to all untrusted code. A practical vision of computing without these things is challenging, though!
  - gryphel 9y ago
    Yes exactly, the problem is non determinism. But I think it should be possible to have deterministic execution while still keeping compatibility with existing software, by replacing the real time with a "fake" time that is deterministic upon the stream of instructions executed, which is on average close to real time. This requires support by the CPU, but it is a relatively simple change, compared to changing speculative execution and caching. Fake time could be kept in sync with real time, by periodically running a privileged process that takes a fixed amount of fake time, but variable amount of real time. (I brought this up in a different comment thread that got marked as duplicate.)
    - voidmain 9y ago
      ... and then you have to make, for example, scheduling of threads based on "fake time". rr does just this! I think it uses the "instructions retired" performance counter as its "fake time"; that turns out to be deterministic enough for its purposes. Whether it's deterministic enough in a security context, I don't know for sure. But this approach, though it can run threaded software, will not let untrusted software (which should really mean all software!) use more than one real core or hardware thread.
      - jakeogh 9y ago
        What's rr?
        jakeogh 9y ago
        found it: https://github.com/mozilla/rr https://github.com/mozilla/rr
frozenport 9y ago
Timing doesn't have to be in seconds. You can spin up a second thread, that increments a variable and use that a your meter stick for elapsed time. Another though is to have the timer on some external server.
pjc50 9y ago
This wrecks a lot of useful things and doesn't really address the problem.
dboreham 9y ago
Please no! Some of us need to do performance analysis. Surely the proper fix is to not expose the sensitive information, rather than to try to constrain the attacker's ability to see it easily? Given that "silicon is cheap" why don't we work around these problems by ensuring that processes within different security domains run on separate cores with their own cache and branch prediction cache? At context-switch, flush all that.
- skybrian 9y ago
  We need to do performance analysis, but sandboxed code usually doesn't. The performance measurement can be in the environment. This is similar to eval(). The operating system always needs a way to load new code, but you don't need it in the language, or least not in a sandboxed language. It's also more consistent with the abstract programming model that we typically use. A new version of a function is normally considered compatible with the previous one based on the values it returns, not the details of its timing (within reason). We often depend on this correctness vs. performance separation to be able to make performance improvements easily. It's very convenient to be able to swap in faster code without worrying that you'll break any callers. It's also convenient not to have to write constant-time functions (to avoid information leaks) most of the time.
  - floatboth 9y ago
    Yeah, and for developers of sandboxed code (i.e. JS/WASM in webpages) precise timing should be available in a special Developer Mode.
otakucode 9y ago
Or just include the timing in your models, and derive from those models a suite of tests that can be run on the hardware to verify that the timing is as it was taken to be in the proven system?

jjuhl 9y ago

But those are all just mitigations, not fixes. Such changes don't guarantee that it's impossible to still leak information - just that it will be harder (but not inherently impossible) to exploit.

nine_k 9y ago
If you increase the number of bits in a hash, you do not guarantee against collisions, but you can make them so infrequent that searching for them becomes impractical. If the randomizations have such an effect that data sniffing is still possible but its speed is 1 bit per week, trying to sniff something interesting becomes impractical. (Or not; depends on your threat model.)
heiei98jejrj282 9y ago
Yes they are just mitigations. What else you got? Firewalls aren’t iron clad they just minimize who can get in There will always be deep, broadly unseen problems; it’s an information availability problem, not a technical one... testing won’t catch some clever edge case a random hacker can come up with because Intel, etc, have to ship, and they ship a design they can produce with information at hand; new deficiencies will be found And those of us in no position to make chips have to suck that up and accept mitigation’s So far no one has come up with a perfect model for any task that requires many layers of context and abstractions; physics, medicine... they’re all racing to find the next blocker and move on. Same with chip makers IMO what needs changing is economics. Information is being hidden and not for security but to protect business models. The economy could have been hit hard if this was known sooner. And having an economy hingeing on that truth, that theres a bug that could disrupt it we just haven’t found it yet, is economic stability and security through obscurity.
voidmain 9y ago
The root of all evil is nondeterminism. A program which executes deterministically cannot receive a timing channel! So "all" we have to do to end this entire class of problems is deny all nondeterministic features, including shared memory threading and timers and two way network communication, to all untrusted code. A practical vision of computing without these things is challenging, though!
- gryphel 9y ago
  Yes exactly, the problem is non determinism. But I think it should be possible to have deterministic execution while still keeping compatibility with existing software, by replacing the real time with a "fake" time that is deterministic upon the stream of instructions executed, which is on average close to real time. This requires support by the CPU, but it is a relatively simple change, compared to changing speculative execution and caching. Fake time could be kept in sync with real time, by periodically running a privileged process that takes a fixed amount of fake time, but variable amount of real time. (I brought this up in a different comment thread that got marked as duplicate.)
  - voidmain 9y ago
    ... and then you have to make, for example, scheduling of threads based on "fake time". rr does just this! I think it uses the "instructions retired" performance counter as its "fake time"; that turns out to be deterministic enough for its purposes. Whether it's deterministic enough in a security context, I don't know for sure. But this approach, though it can run threaded software, will not let untrusted software (which should really mean all software!) use more than one real core or hardware thread.
    - jakeogh 9y ago
      What's rr?
      - jakeogh 9y ago
        found it: https://github.com/mozilla/rr https://github.com/mozilla/rr

frozenport 9y ago

Timing doesn't have to be in seconds. You can spin up a second thread, that increments a variable and use that a your meter stick for elapsed time. Another though is to have the timer on some external server.

pjc50 9y ago

This wrecks a lot of useful things and doesn't really address the problem.

dboreham 9y ago

Please no! Some of us need to do performance analysis. Surely the proper fix is to not expose the sensitive information, rather than to try to constrain the attacker's ability to see it easily? Given that "silicon is cheap" why don't we work around these problems by ensuring that processes within different security domains run on separate cores with their own cache and branch prediction cache? At context-switch, flush all that.

skybrian 9y ago
We need to do performance analysis, but sandboxed code usually doesn't. The performance measurement can be in the environment. This is similar to eval(). The operating system always needs a way to load new code, but you don't need it in the language, or least not in a sandboxed language. It's also more consistent with the abstract programming model that we typically use. A new version of a function is normally considered compatible with the previous one based on the values it returns, not the details of its timing (within reason). We often depend on this correctness vs. performance separation to be able to make performance improvements easily. It's very convenient to be able to swap in faster code without worrying that you'll break any callers. It's also convenient not to have to write constant-time functions (to avoid information leaks) most of the time.
- floatboth 9y ago
  Yeah, and for developers of sandboxed code (i.e. JS/WASM in webpages) precise timing should be available in a special Developer Mode.

otakucode 9y ago

Or just include the timing in your models, and derive from those models a suite of tests that can be run on the hardware to verify that the timing is as it was taken to be in the proven system?