Side Channel Attacks are No Joke
I was reading about WebAssembly's specification and was hoping to share some learnings here. As usual I got kind of side tracked and was trying to understand more about the security guarantees of Wasm. While I haven't been digging into memory management yet, one the notes that are part of the introduction is the following:
"No program can break WebAssembly’s memory model. Of course, it cannot guarantee that an unsafe language compiling to WebAssembly does not corrupt its own memory layout, e.g. inside WebAssembly’s linear memory."
Which is definitely a good thing to have. This means that memory direct access concerns across sandboxes are non-existent (gentle reminder that I am deducing this from just the intro so I don't have the details yet). That made me feel pretty good about memory isolation. As I continued reading the security section, I stumbled upon this:
"Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level"
Uh oh. Side channel attacks are mentioned quite often when it comes to security and isolation concerns. I wanted to understand a little more about it to find out that not only are they difficult to do, also a bit more complex to explain than I hoped. To be precise, I would not be able to fit it in a thought. The gist of it (and I feel terribly guilty for butchering this and oversimplifying) is that these are hardware level attacks, as a Software Engineer there seems to be very little we can do. Or so I thought.
Alright let me expand a bit. I believe the reason why they are called side channel attacks is because they don't interfere or intervene directly with an application. If you were to write malicious software that tries to access memory outside of its boundaries to steal information, that would be a direct attack. In other terms they try to breach software or hardware defenses. A side channel one leverages meta information dependent on the hardware or system it's running on. An example could be trying to steal a secret. Rather than trying to access the memory containing the secret directly you would perform signal analysis on the electromagnetic radiation emitted from a device, energy consumption of the system, or temperature measurement.
I didn't make it any simpler did I? Alright, that was also a bit too informative and not informative enough. As you can imagine, any machine or hardware has to physically do some work to execute a calculation, it might take a certain amount of time, or it might do such intense work that the temperature of the hardware reaches a certain level. By studying these patterns an attacker could determine what the machine is trying to calculate or do. A very silly example (also not realistic because I don't know how these attacks are perpetrated) would be that a device reaches the temperature of 85F every time it needs to multiply something by 100. If an attacker knows this it could monitor the temperature of the device and know that when it reaches 85F it is most likely multiplying something by 100. I think this short video shows you a practical example that will get the point across better than I did, here they try to guess the PIN of a hardware wallet by studying its unintended behavior (e.g. energy consumption).
Thoughts
Side channel attacks are pretty wild. I was hoping to read more about it but I don't think a few blog posts here and there will be enough. Know that common isolation techniques like Hypervisor level VM isolation help mitigate this. Especially if you're worried (as you should) about cross-VM attacks. There are other counter-measurements that security experts can take in these case and some things we can do as engineers as best practices include: timing-attack-resistant algorithms (I think this is why some cloud functions won't really expose a clock and if you try to get the current time, you will always get the same result no matter where you log this in your function), constant-time programming techniques (algorithms that execute in constant time no matter the size of the input), and probably more. To learn more about how scary side channel attacks can be, you should look into the Spectre vulnerability disclosed in 2018.