5 ms·

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 no

by 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
- floatboth 9y ago
  We can also try to avoid concurrently executing untrusted code on a single processor? At least on the server side, that's realistic. Big companies like Google already run their own trusted code on their own hardware. For everyone else, it's not impossible to move from VPS hosting to "bare metal cloud" like Scaleway offers. (Vision for the Future™: instead of their tied-to-Linux "someone else's Raspberry Pi" experience, it would be a bunch of tiny single core processors, each connected to their own tiny DRAM chip. You upload unikernel images or CloudABI binaries (that would be then wrapped into unikernels) into the Cloud™, where the load balancer boots up your images on-demand on as many of these tiny computers as needed. RAM is zeroed before boot.) The other big environment with tons of untrusted code is of course the web browser. This is significantly more ridiculous, but: why not embed a ton of tiny simple in-order ARM cores without any shared cache into desktop processors, and run JS/WASM on them? (One core used per origin per site) :D

by 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
floatboth 9y ago
We can also try to avoid concurrently executing untrusted code on a single processor? At least on the server side, that's realistic. Big companies like Google already run their own trusted code on their own hardware. For everyone else, it's not impossible to move from VPS hosting to "bare metal cloud" like Scaleway offers. (Vision for the Future™: instead of their tied-to-Linux "someone else's Raspberry Pi" experience, it would be a bunch of tiny single core processors, each connected to their own tiny DRAM chip. You upload unikernel images or CloudABI binaries (that would be then wrapped into unikernels) into the Cloud™, where the load balancer boots up your images on-demand on as many of these tiny computers as needed. RAM is zeroed before boot.) The other big environment with tons of untrusted code is of course the web browser. This is significantly more ridiculous, but: why not embed a ton of tiny simple in-order ARM cores without any shared cache into desktop processors, and run JS/WASM on them? (One core used per origin per site) :D