Comment by d0vs
6 hours ago
As someone who develops microVMs it doesn't really matter to me that they were asked to find a way, I really care that they found any way at all. MicroVMs aim to protect against malicious workloads and that clearly didn't work here.
The microVMs probably don't have "two co-operating workloads are able to communicate" in their threat model. The main concern would be if a malicious payload was able to affect or extract data from any other VM.
I had to read this a few times. The difference is that with the OpenAI case there were two willing and determined parties, whereas the typical attack vector a microvm traditionally deals with is one malicious or compromised microVM trying extract data from another unwilling one.
Yes — and this isn’t really an attack. It’s an open signal channel between two microvm’s. If there was nobody intentionally listening in the other side you can shout into the ether as much as you want with no harm done.
The receiving side could be seen as a side channel attack, but not unique to LLMs.
Ask the least smart LLM you have access to (I tried gemini lite flash) to make a list of ways for processes in microVMs to use a sidechannel attack to talk to each other and you'll get quite a list (including obviously cache hits/misses). Heck a smart CS junior would come up with it. It's well studied!
> Ask the least smart LLM
> Heck a smart CS junior would come up with it.
That’s somewhat worrisome.
LLM can recite it because it's in the training data (or Google it). CS Junior could invent it independently.
I'd like to see an LLM-aided implementation of row hammer being used for something like this.
this is just for common designs..you can design much better than common designs if you free your mind from old OS dev thinking if you read all the manuals yourself.
AI wont help u there :-). they will tell u how to build what others already did, which obviously is not good enough
I don't think that's the full picture. If you include these manuals as reference for a strong model, it will reason pretty well based off of that, I recon.
Making a list is one thing, executing a real attack is another.
Both workloads being malicious and trying to establish a hidden data channel between them probably makes this attack a lot easier than conventional spectre/meltdown where it's trying to target ordinary processes that are not intentionally trying to be loud.
Hidden data channel between cooperating processes is not quite as alarming, but it may have some implications for malware command and control.
The distinction is interesting, but for a different concern. One thing is to have rogue models breaking stuff, other is to have them following orders, and breaking stuff with success.
This means cloud models can have some guardrails and follow them most of the time (we could model their authorizations like a benign employee with permission to break glass during incidents). But self hosted models can avoid that and help malicious people do advanced attacks, which is a shame.
In principle I'm all for self hosted models, to avoid risks of AI centralization, but they also have other types of risks.
Seems like a win to me. Their microvms can now be hardened in the lab, not in an emergency :)
Makes sense when you think about it- CPU cache would be a layer / vulnerability level up from the microVM layer
Also a somewhat common exploit pattern for low level stuff (along with dram and cpu cache is not all that different)
properly implementing things like iommu, amd-vi, svm/hvms and such things more granularly can easily avoid this kind of crap. it costs a lot of processing and performance which is why people skip over it or dont do it.. or maybe they dont read CPU manuals anymore. idk..
its relatively easy to reset caches etc. between contexts. so them it becomes the game of what a context is.
I’m not sure I see a real threat here.
If you’re running an untrusted workload, you’re already running it.
Whether it can communicate with another untrusted workload, even though it should be separated, meh.
Unexpected? Probably. but I’m not sure it’s a security risk.
you might have an untrusted sandboxed workload that is not supposed to communicate externally handling secrets, and a different sandboxed workload able to communicate with the external world, not handling secrets.
The solution is to not have an untrusted workload handle secrets.
1 reply →
[flagged]