6 ms·

I wonder how much sooner than google did intel employees found this issue

narinxas 3y ago
but what I am really wondering about is how much money (if any) was the vulnerability worth up the moment when google also discovered this?
- ajross 3y ago
  As described it's just a CPU crash exploit that requires local binary execution. Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel. So as described, this isn't a "valuable" bug.
  - derefr 3y ago
    This assumes that either 1. partners and interested sponsor-state state actors aren't kept abreast Intel's microcode backend architecture, or 2. that there hasn't been at least one leak of this information from one of these partners into the hands of interested APT developers. I wouldn't put strong faith in either of these assumptions.
    - ajross 3y ago
      It does, but the same is true for virtually any such crash vulnerability. The question was whether this was a "valuable exploit", not whether it might theoretically be worse. The space of theoretically-very-bad attacks is much larger than practical ones people will pay for, c.f. rowhammer.
      - ethbr1 3y ago
        >> Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel. Intel knows exactly how their ROB works. Therefore Intel knows the possible consequences of this bug and how to trigger them. If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew. Thankfully, since it's public now, the value of that decreases and customers can begin to mitigate.
        ajross 3y ago
        > If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew. No, or at least not yet. I mean, I've written plenty of bugs. More than I can count. How many of them were genuine security vulnerabilities if properly exploited? Probably not zero. But... I don't know. And I wrote the code!
        saagarjha 3y ago
        Intel said it can be used for escalation if that answers your question.
        lmm 3y ago
        Did they confirm that it can definitely be used for escalation? The description I saw was "may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access" which sounds like they're covering all their bases and may not actually know what is and isn't possible.
  - dgacmu 3y ago
    It's not super-valuable yet, but it would keep you mount a really nasty DoS on cloud providers by triggering hard resets of the physical machines. Some people would probably pay for that, though it's obviously more interesting to push on privilege or exfiltration. Particularly since the MCEs triggered could prevent an automatic reboot. Would depend what the hardware management system did - do machines presenting MCEs get pulled?
    - toast0 3y ago
      If I'm a cloud provider and somebody's workflow is hard resetting lots of my physical machines, I'm going to give them free access to single tenant machines at the very minimum. If they keep crashing the machines that only they run on, I guess that's ok.
      - dgacmu 3y ago
        You can exploit this from a single core shared instance. So you go and find yourself a thousand cheap / free tier accounts, spin up an instance in a few regions each, and boom, you've taken out 10k physical hosts. And run it in a lambda at the same time, and see how well the security mechanisms identify and isolate you. Causing a near simultaneous reboot of enough hosts is likely to take other parts of the infrastructure down.
        ajross 3y ago
        I'm curious what part of this scheme involves "not ending up in jail"? Needless to say you can't do this without identifying yourself. To make this an exploitable DoS attack you need to be able to run arbitrary binaries on a few thousand cloud hosts that you didn't lease yourself.
        blibble 3y ago
        there exist people outside of your jurisdiction e.g. the GRU
        TeMPOraL 3y ago
  - sweetjuly 3y ago
    The blogpost describes that unrelated sibling SMT threads can become corrupted and branch erratically. If you can get a hypervisor thread executing as your SMT sibling and you can figure out how to control it (this is not an if so much as a when), that's a VM escape. The Intel advisory acknowledges this too when they say it can lead to privilege escalation. This is hardly a useless bug, in fact it's awfully powerful!
  - nrabulinski 3y ago
    Intel themselves said it could lead to privilege escalation and a friend of mine (who coincidentally was responsible for this Intel-related talk: https://youtu.be/Zda7yMbbW7s https://youtu.be/Zda7yMbbW7s) already managed to get privilege escalation with it, though I’m not sure if he’ll want to share any details, at least for now. It’s anything but a minor bug and anyone that says so clearly hasn’t worked with CPUs

but what I am really wondering about is how much money (if any) was the vulnerability worth up the moment when google also discovered this?

ajross 3y ago
As described it's just a CPU crash exploit that requires local binary execution. Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel. So as described, this isn't a "valuable" bug.
- derefr 3y ago
  This assumes that either 1. partners and interested sponsor-state state actors aren't kept abreast Intel's microcode backend architecture, or 2. that there hasn't been at least one leak of this information from one of these partners into the hands of interested APT developers. I wouldn't put strong faith in either of these assumptions.
  - ajross 3y ago
    It does, but the same is true for virtually any such crash vulnerability. The question was whether this was a "valuable exploit", not whether it might theoretically be worse. The space of theoretically-very-bad attacks is much larger than practical ones people will pay for, c.f. rowhammer.
    - ethbr1 3y ago
      >> Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel. Intel knows exactly how their ROB works. Therefore Intel knows the possible consequences of this bug and how to trigger them. If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew. Thankfully, since it's public now, the value of that decreases and customers can begin to mitigate.
      - ajross 3y ago
        > If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew. No, or at least not yet. I mean, I've written plenty of bugs. More than I can count. How many of them were genuine security vulnerabilities if properly exploited? Probably not zero. But... I don't know. And I wrote the code!
        saagarjha 3y ago
        Intel said it can be used for escalation if that answers your question.
        lmm 3y ago
        Did they confirm that it can definitely be used for escalation? The description I saw was "may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access" which sounds like they're covering all their bases and may not actually know what is and isn't possible.
- dgacmu 3y ago
  It's not super-valuable yet, but it would keep you mount a really nasty DoS on cloud providers by triggering hard resets of the physical machines. Some people would probably pay for that, though it's obviously more interesting to push on privilege or exfiltration. Particularly since the MCEs triggered could prevent an automatic reboot. Would depend what the hardware management system did - do machines presenting MCEs get pulled?
  - toast0 3y ago
    If I'm a cloud provider and somebody's workflow is hard resetting lots of my physical machines, I'm going to give them free access to single tenant machines at the very minimum. If they keep crashing the machines that only they run on, I guess that's ok.
    - dgacmu 3y ago
      You can exploit this from a single core shared instance. So you go and find yourself a thousand cheap / free tier accounts, spin up an instance in a few regions each, and boom, you've taken out 10k physical hosts. And run it in a lambda at the same time, and see how well the security mechanisms identify and isolate you. Causing a near simultaneous reboot of enough hosts is likely to take other parts of the infrastructure down.
      - ajross 3y ago
        I'm curious what part of this scheme involves "not ending up in jail"? Needless to say you can't do this without identifying yourself. To make this an exploitable DoS attack you need to be able to run arbitrary binaries on a few thousand cloud hosts that you didn't lease yourself.
        blibble 3y ago
        there exist people outside of your jurisdiction e.g. the GRU
        TeMPOraL 3y ago
- sweetjuly 3y ago
  The blogpost describes that unrelated sibling SMT threads can become corrupted and branch erratically. If you can get a hypervisor thread executing as your SMT sibling and you can figure out how to control it (this is not an if so much as a when), that's a VM escape. The Intel advisory acknowledges this too when they say it can lead to privilege escalation. This is hardly a useless bug, in fact it's awfully powerful!
- nrabulinski 3y ago
  Intel themselves said it could lead to privilege escalation and a friend of mine (who coincidentally was responsible for this Intel-related talk: https://youtu.be/Zda7yMbbW7s https://youtu.be/Zda7yMbbW7s) already managed to get privilege escalation with it, though I’m not sure if he’ll want to share any details, at least for now. It’s anything but a minor bug and anyone that says so clearly hasn’t worked with CPUs