4 ms·

Has there been an in-the-wild exploit found for many of these micro-arch side channel attacks? I still have reservations that Specter can be actually exploited

Has there been an in-the-wild exploit found for many of these micro-arch side channel attacks? I still have reservations that Specter can be actually exploited, and certainly not by JavaScript running in a browser it seems (even without the timing fixes -- just too much noise in the system to get a real world exploit). All the proof of concepts I saw effectively needed a running start (and a much lower bar to clear). I'm still not sure if we are just making too much out of many of these attacks. Also, many of these exploits require running native code to really even be possible, and a JIT offers a large degress of protection. Most of the machines I use, if you are already able to run native code, the battle has already been lost. I think the security community can sometimes have Chicken Little syndrome. I most definitely wouldn't want performance enhancing techniques that might have side-channel vulnerabilities to not be produced or used because they might be exploitable in a use case (eg, web serving and rendering) that doesn't fit most others (eg, internal servers).

dwheeler 8y ago
> I still have reservations that Specter can be actually exploited It's not easy, and many systems are more easily broken into by other means (e.g., unpatched known-vulnerable programs). But people are already demonstrating exploits; it's not theoretical. > and certainly not by JavaScript running in a browser it seems (even without the timing fixes -- just too much noise in the system to get a real world exploit). Your faith is unwarranted. The paper itself evaluated JavaScript as implemented by v8, which is used by Chrome: "as part of our defensive work, we implemented a number of the described mitigations in the V8 JavaScript virtual machine and evaluated their performance penalties. As we’ve noted, none of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off." Also, modern statistics is pretty amazing at removing noise. Don't make claims about "too much noise" until you've tried them. > Most of the machines I use, if you are already able to run native code, the battle has already been lost. Perhaps, but many others are in a different circumstance. We've moved to a world where people run on clouds (shared machines with your enemy) and automatically run JavaScript provided by malicious parties. This isn't hopeless. You can run on clouds but run on temporarily-isolated CPUs so there's no leak. A lot of applications can be easily written to work without JavaScript (though many can't, and many developers have no idea that this might be desirable). For many, providing confidentiality when the CPUs always leak is a real problem. > I think the security community can sometimes have Chicken Little syndrome. That's certainly true. These are not easy to exploit today, especially given some mitigations. But think of these as warning shots - these are problems for which there is NO practical full mitigation today. It would be unwise to ignore the problem. Attackers are likely to gradually get better at exploiting this over time, and if that happens, the only solution available is to NOT share CPUs running programs (disable JavaScript and use more-expensive isolated-CPU clouds) OR replace most CPUs with CPUs that do not yet exist. > I most definitely wouldn't want performance enhancing techniques that might have side-channel vulnerabilities to not be produced or used because they might be exploitable in a use case (eg, web serving and rendering) that doesn't fit most others (eg, internal servers). Understandable, and that may be just fine for your situation. However, most systems try to use least privilege to reduce damage (e.g., if you break into one component, you don't get everything). This attack makes it easier to breach such isolation - so even in that case, you might have reason to be concerned. The sky is not falling, at least not today. But there are reasons to be concerned.
pcwalton 8y ago
I agree that Spectre is somewhat overblown. It's something that we should be working on mitigating, to be sure, but it is very difficult to exploit. Memory safety issues, in practice, are significantly easier to find, so that's what attackers go for. We're not in a "drop everything, all hands on deck" situation.
YorkshireSeason 8y ago
The article states in Section 4.5 (Page 20): As part of our offensive work, we developed proofs of concept in C++, JavaScript, and WebAssembly for all the reported vulnerabilities. We were able to leak over 1KB/s from variant 1 gadgets in C++ using rdtsc with 99.99% accuracy and over 10B/s from JavaScript using a low resolution timer.
- icedchai 8y ago
  This is nice, but is there a real world exploit, not a POC? Example: pulling session cookies for another site, or extracting an SSH private key?
  - xenadu02 8y ago
    What are you basing this unearned confidence on? We've seen this same pattern repeat thousands of times: 1. This might be a vulnerability in theory but there's no POC 2. Well it's just a POC, no one has actually weaponized this. 3. Sure someone weaponized this but it is very difficult to pull off. 4. Oh the script-kiddie toolkits can build exploits for this automatically. Who could have seen it coming?!? (Step #2 is probably where the various governmental spying agencies start deploying the exploit in targeted ways) Perhaps this time things are different but it seems unlikely.
    - icedchai 8y ago
      Reading 10B/sec from JS, which is under ideal conditions, does not sound like a fast path to exploitation. I agree it is a concern, but I think it is overblown, similar to pcwalton below.
  - jnordwick 8y ago
    There has not been an instance of a real world exploit being run (e.g, you don't know what memory address you are attacking and the system is running under a real world load), and I saw a release by a con sec company (can't remember which one) that said they haven't seen any indication anybody was trying this in the wild either. There is so much that needs to line up to get Specter to work in Javascript that I'm at the point that I don't think it is possible. Everybody keep saying that the POC shows it is possible and that a real world exploit is easy after that. But Specter has been around for a year now, and nobody has yet to even get close to make a working exploit that didn't require some large leaps of faith. And every time you bring this up, you get voted into the floor in HN. I get it. Specter is very cool, almost magical, but coolness doesn't make it any more likely to work.

dwheeler 8y ago

> I still have reservations that Specter can be actually exploited It's not easy, and many systems are more easily broken into by other means (e.g., unpatched known-vulnerable programs). But people are already demonstrating exploits; it's not theoretical. > and certainly not by JavaScript running in a browser it seems (even without the timing fixes -- just too much noise in the system to get a real world exploit). Your faith is unwarranted. The paper itself evaluated JavaScript as implemented by v8, which is used by Chrome: "as part of our defensive work, we implemented a number of the described mitigations in the V8 JavaScript virtual machine and evaluated their performance penalties. As we’ve noted, none of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off." Also, modern statistics is pretty amazing at removing noise. Don't make claims about "too much noise" until you've tried them. > Most of the machines I use, if you are already able to run native code, the battle has already been lost. Perhaps, but many others are in a different circumstance. We've moved to a world where people run on clouds (shared machines with your enemy) and automatically run JavaScript provided by malicious parties. This isn't hopeless. You can run on clouds but run on temporarily-isolated CPUs so there's no leak. A lot of applications can be easily written to work without JavaScript (though many can't, and many developers have no idea that this might be desirable). For many, providing confidentiality when the CPUs always leak is a real problem. > I think the security community can sometimes have Chicken Little syndrome. That's certainly true. These are not easy to exploit today, especially given some mitigations. But think of these as warning shots - these are problems for which there is NO practical full mitigation today. It would be unwise to ignore the problem. Attackers are likely to gradually get better at exploiting this over time, and if that happens, the only solution available is to NOT share CPUs running programs (disable JavaScript and use more-expensive isolated-CPU clouds) OR replace most CPUs with CPUs that do not yet exist. > I most definitely wouldn't want performance enhancing techniques that might have side-channel vulnerabilities to not be produced or used because they might be exploitable in a use case (eg, web serving and rendering) that doesn't fit most others (eg, internal servers). Understandable, and that may be just fine for your situation. However, most systems try to use least privilege to reduce damage (e.g., if you break into one component, you don't get everything). This attack makes it easier to breach such isolation - so even in that case, you might have reason to be concerned. The sky is not falling, at least not today. But there are reasons to be concerned.

pcwalton 8y ago

I agree that Spectre is somewhat overblown. It's something that we should be working on mitigating, to be sure, but it is very difficult to exploit. Memory safety issues, in practice, are significantly easier to find, so that's what attackers go for. We're not in a "drop everything, all hands on deck" situation.

YorkshireSeason 8y ago

The article states in Section 4.5 (Page 20): As part of our offensive work, we developed proofs of concept in C++, JavaScript, and WebAssembly for all the reported vulnerabilities. We were able to leak over 1KB/s from variant 1 gadgets in C++ using rdtsc with 99.99% accuracy and over 10B/s from JavaScript using a low resolution timer.

icedchai 8y ago
This is nice, but is there a real world exploit, not a POC? Example: pulling session cookies for another site, or extracting an SSH private key?
- xenadu02 8y ago
  What are you basing this unearned confidence on? We've seen this same pattern repeat thousands of times: 1. This might be a vulnerability in theory but there's no POC 2. Well it's just a POC, no one has actually weaponized this. 3. Sure someone weaponized this but it is very difficult to pull off. 4. Oh the script-kiddie toolkits can build exploits for this automatically. Who could have seen it coming?!? (Step #2 is probably where the various governmental spying agencies start deploying the exploit in targeted ways) Perhaps this time things are different but it seems unlikely.
  - icedchai 8y ago
    Reading 10B/sec from JS, which is under ideal conditions, does not sound like a fast path to exploitation. I agree it is a concern, but I think it is overblown, similar to pcwalton below.
- jnordwick 8y ago
  There has not been an instance of a real world exploit being run (e.g, you don't know what memory address you are attacking and the system is running under a real world load), and I saw a release by a con sec company (can't remember which one) that said they haven't seen any indication anybody was trying this in the wild either. There is so much that needs to line up to get Specter to work in Javascript that I'm at the point that I don't think it is possible. Everybody keep saying that the POC shows it is possible and that a real world exploit is easy after that. But Specter has been around for a year now, and nobody has yet to even get close to make a working exploit that didn't require some large leaps of faith. And every time you bring this up, you get voted into the floor in HN. I get it. Specter is very cool, almost magical, but coolness doesn't make it any more likely to work.