NetSpectre: Read Arbitrary Memory Over Network [pdf]
1–10 of 24 posts
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#2In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get better over time, but still, that's an AES key in a few days, and it assumes one discrete target; in a real deployment, that secret might be mirrored over hundreds of instances.
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#3The AVX side channel is neat. It relies on power management rather than cache: after 1ms of AVX2 inactivity (no 256 bit operations being performed), it goes into a power-saving mode; the next 256-bit operation pays a ~2x cycle penalty. They get 8B/min at low error rate with AVX2. In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get b…
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#4The AVX side channel is neat. It relies on power management rather than cache: after 1ms of AVX2 inactivity (no 256 bit operations being performed), it goes into a power-saving mode; the next 256-bit operation pays a ~2x cycle penalty. They get 8B/min at low error rate with AVX2. In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get b…
Mitigating those will be bad for power usage and performance. We can imagine future processors will manage cache state differently, keeping all changes local to the core until the relevant instructions retire. I have no idea how you would mitigate functional unit power up / power down without destroying the usefulness of the feature itself.
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#5Is code for this victim program available? I don't see it in the paper.
Have such gadgets been found in any real-world programs?
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#6The AVX side channel is neat. It relies on power management rather than cache: after 1ms of AVX2 inactivity (no 256 bit operations being performed), it goes into a power-saving mode; the next 256-bit operation pays a ~2x cycle penalty. They get 8B/min at low error rate with AVX2. In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get b…
It's an AES key if you know where to look. Do these style of attacks let you view the memory map or do you just pick a place? How troublesome is this, really? I'm actually curious. I never saw where you find the point in memory to point your Spectre gun.
Like I said, I don't know the specifics, but there are methods of doing better than guessing.
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#7The paper seems to say that they attacked a victim program that was specifically written to include vulnerable gadgets. Is code for this victim program available? I don't see it in the paper. Have such gadgets been found in any real-world programs?
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#8The paper seems to say that they attacked a victim program that was specifically written to include vulnerable gadgets. Is code for this victim program available? I don't see it in the paper. Have such gadgets been found in any real-world programs?
Checking a user provided index is valid before using it is certainly a common idiom. There are many reasons why attacking programs in the wild would be more complicated, but delaying publication until then is probably a poor option. The contribution here is not a single attack against vuln ware release 2.3.12, but a new (or expanded) attack class.
It's certainly interesting to construct an example and show it working, but this isn't surprising, is it?
Just trying to understand if I've missed something here.
(The AVX side channel is certainly new and interesting, though!)
Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#9Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]
#10Earlier quoted context omitted.
Checking a user provided index is valid before using it is certainly a common idiom. There are many reasons why attacking programs in the wild would be more complicated, but delaying publication until then is probably a poor option. The contribution here is not a single attack against vuln ware release 2.3.12, but a new (or expanded) attack class.
Right but didn't we already know that this hypothetical attack class exists? The possibility of remote spectre exploits like this was discussed in the original spectre paper. It's certainly interesting to construct an example and show it working, but this isn't surprising, is it? Just trying to understand if I've missed something here. (The AVX side channel is certainly new and interesting, though!)
Further, it shows how to do it (classifier) and gives a very good model for what bandwidth can be expected in practice. And still further, that bandwidth is entirely sufficient for attacking long lived cryptographic key material. Before, it was easy to theorize that the bandwidth would simply be too low. Now it isn't.
This is also really good because the bandwidth is really low. For data larger than a key (or where you would need to scan a lot to find the data), we can be much more comfortable with infeasibility arguments by basing them on some security margin beyond these experiments. As an example, if it would take 1 to exfiltrate a single credit card number even if the technique got 10 times better, maybe that means it isn't a sufficient risk. Or maybe it is. (All depends on the time unit and the risk.) But now we can make that assessment with a real baseline instead of a guess.