This does indeed defeat operating system privilege-model based sandboxing, and might also defeat software virtualization-based sandboxing (no PoC).
This is why I advocate, when superintelligence seems near, the use of overlapping, qualitatively dissimilar sandboxing mechanisms. Rowhammer does not defeat language semantics-based sandboxing mechanisms, because it requires settings up an anomalous instruction stream, with a very high density of cache-flush instructions; an AI could only do that if it had the ability to create and run new code for itself, bypassing your compiler. Nor does it defeat network-topology based sandboxing mechanisms. In addition to that, RowHammer takes a long time and leaves evidence in hardware counters; a properly-engineered containment system would shut down its contents as soon as the attack started.
Rowhammer does not defeat language semantics-based sandboxing mechanisms, because it requires settings up an anomalous instruction stream, with a very high density of cache-flush instructions; an AI could only do that if it had the ability to create and run new code for itself, bypassing your compiler.
But that’s exactly what Rowhammer.js accomplished! They POCd Javascript code that, given a certain Javascript compiler (JITter), causes binary code to be output that triggers Rowhammer. Thus it escaped the langauge semantics based sandbox.
As long as your compiler doesn’t deliberately avoid outputting binary code with a particular property (e.g. rowhammering), it might be possible to choose compiler input that will create the desired output.
Hmm. Papers [2] and [3] demonstrate an attack starting from a position of executing native code; [4] I didn’t read until just now, and that’s the one that works within Javascript’s semantics.
They had three test machines: a Sandy Bridge laptop, an Ivy Bridge laptop, and a Haswell desktop. The Sandy Bridge laptop seems to have only been used for studying its cache-eviction policy, they don’t report a result (positive or negative) for getting it to flip bits. They studied three memory-corruption strategies: in descending order of strength, clflush, evict (native), and evict (JavaScript). The first strategy (clflush) is the previously-discussed strategy using cache-flush instructions, which can only be done from native code with a highly unusual instruction mix. The two evict strategies work by making a pattern of memory accesses which interacts with the processor’s caching rules. The clflush version requires executing native code; the evict strategies work if the code is JITted.
All three strategies worked against the Ivy Bridge test machine. None of the strategies worked against the Haswell test machine. (They note that Lenovo released a BIOS update which decreases the memory refresh interval, which would likely make it resistant, which they didn’t test). They then went on to change the Haswell’s memory refresh interval in the BIOS settings, and compared the rate of bit flips with the three different strategies at different memory refresh intervals (figs. 4 and 5). The eviction-based strategies start causing bit flips at a refresh interval that’s slightly more than twice as long as the clflush based strategies; the native and Javascript evict-based strategies started producing bit flips at very close to the same refresh interval.
They did not build a root exploit out of the Javascript version, and to get bit flips at all, they used a modified Javascript interpreter which provides an inverted page table. This is a fairly substantial cheat. They think they could make a root exploit out of this, and I believe them, but the difficulty is quite a lot higher than the clflush-based version and it has not in fact been accomplished.
So to summarize—code running through a JITter is in fact at a large disadvantage when trying to exploit you, just not quite so large a disadvantage that you should feel invulnerable. Stepping back to the bigger picture, assuming RowHammer will be fixed but other vulnerabilities will remain, I expect that language semantics-based sandboxing will protect from many, likely most, but not quite all of them.
While air gaps are probably the closest thing to actual computer security I can imagine, even that didn’t work out so well for the guys at Natanz…
And once you have systems on both sides of the air gap infected, you can even use esoteric techniques like ultrasound from the internal speaker to open up a low bandwith connection to the outside.
Even if you don’t have systems on the far side of the air gap infected, you can still e.g. steal private keys from their CPUs by analyzing EM or acoustic leakage. So in addition to an air gap, you need an EM gap (Faraday cage) and an acoustic gap (a room soundproofed for all the right frequencies).
In general, any physical channel that leaks information might be exploited.
This does indeed defeat operating system privilege-model based sandboxing, and might also defeat software virtualization-based sandboxing (no PoC).
This is why I advocate, when superintelligence seems near, the use of overlapping, qualitatively dissimilar sandboxing mechanisms. Rowhammer does not defeat language semantics-based sandboxing mechanisms, because it requires settings up an anomalous instruction stream, with a very high density of cache-flush instructions; an AI could only do that if it had the ability to create and run new code for itself, bypassing your compiler. Nor does it defeat network-topology based sandboxing mechanisms. In addition to that, RowHammer takes a long time and leaves evidence in hardware counters; a properly-engineered containment system would shut down its contents as soon as the attack started.
But that’s exactly what Rowhammer.js accomplished! They POCd Javascript code that, given a certain Javascript compiler (JITter), causes binary code to be output that triggers Rowhammer. Thus it escaped the langauge semantics based sandbox.
As long as your compiler doesn’t deliberately avoid outputting binary code with a particular property (e.g. rowhammering), it might be possible to choose compiler input that will create the desired output.
Hmm. Papers [2] and [3] demonstrate an attack starting from a position of executing native code; [4] I didn’t read until just now, and that’s the one that works within Javascript’s semantics.
They had three test machines: a Sandy Bridge laptop, an Ivy Bridge laptop, and a Haswell desktop. The Sandy Bridge laptop seems to have only been used for studying its cache-eviction policy, they don’t report a result (positive or negative) for getting it to flip bits. They studied three memory-corruption strategies: in descending order of strength, clflush, evict (native), and evict (JavaScript). The first strategy (clflush) is the previously-discussed strategy using cache-flush instructions, which can only be done from native code with a highly unusual instruction mix. The two evict strategies work by making a pattern of memory accesses which interacts with the processor’s caching rules. The clflush version requires executing native code; the evict strategies work if the code is JITted.
All three strategies worked against the Ivy Bridge test machine. None of the strategies worked against the Haswell test machine. (They note that Lenovo released a BIOS update which decreases the memory refresh interval, which would likely make it resistant, which they didn’t test). They then went on to change the Haswell’s memory refresh interval in the BIOS settings, and compared the rate of bit flips with the three different strategies at different memory refresh intervals (figs. 4 and 5). The eviction-based strategies start causing bit flips at a refresh interval that’s slightly more than twice as long as the clflush based strategies; the native and Javascript evict-based strategies started producing bit flips at very close to the same refresh interval.
They did not build a root exploit out of the Javascript version, and to get bit flips at all, they used a modified Javascript interpreter which provides an inverted page table. This is a fairly substantial cheat. They think they could make a root exploit out of this, and I believe them, but the difficulty is quite a lot higher than the clflush-based version and it has not in fact been accomplished.
So to summarize—code running through a JITter is in fact at a large disadvantage when trying to exploit you, just not quite so large a disadvantage that you should feel invulnerable. Stepping back to the bigger picture, assuming RowHammer will be fixed but other vulnerabilities will remain, I expect that language semantics-based sandboxing will protect from many, likely most, but not quite all of them.
What’s a network topology based sandboxing mechanism?
A fancy way of saying “don’t have a wire or path of wires leading to the internet”.
While air gaps are probably the closest thing to actual computer security I can imagine, even that didn’t work out so well for the guys at Natanz… And once you have systems on both sides of the air gap infected, you can even use esoteric techniques like ultrasound from the internal speaker to open up a low bandwith connection to the outside.
Even if you don’t have systems on the far side of the air gap infected, you can still e.g. steal private keys from their CPUs by analyzing EM or acoustic leakage. So in addition to an air gap, you need an EM gap (Faraday cage) and an acoustic gap (a room soundproofed for all the right frequencies).
In general, any physical channel that leaks information might be exploited.