3 ms·

> the exploit on a guest machine causes the host machine to crash resulting in a Denial of Service to other guest machines running on the same host. Additionall

> the exploit on a guest machine causes the host machine to crash resulting in a Denial of Service to other guest machines running on the same host. Additionally, the vulnerability could potentially lead to information disclosure I don't quite understand how this issue can be a DoS vector, and 'maybe' lead to info disclosure... If the only issue is that a machine check exception is thrown when it shouldn't be, then I don't see how that leads to info disclosure...

valenterry 3y ago
I guess it also could 'maybe' lead to people dying... under the right circumstances. In other words: just marketing.
adrian_b 3y ago
It is not an exception. That would have happened if the CPUs had not been buggy. It is a crash that requires a reboot of the computer. Therefore a rogue VM can take down the hypervisor and all the other VMs hosted on the same server. The bug is that according to the x86-64 ISA specification that sequence of instruction prefixes should have caused an illegal instruction exception, but it does not cause any exception. Instead of that, it desynchronizes the microcode execution and the CPU executes other microinstructions than it should, leading into a crash.
danpalmer 3y ago
If you can get the exception thrown only when another process has a particular state, or if that other process's state can affect the timing of the exception throw, then that's information disclosure. Typically these are are hard to pull off, I remember a case a number of years ago where the proof of concept private key exfiltration came months or maybe even a year after the vulnerability was shown, and even then I believe the process took minutes or perhaps hours to run. This stuff isn't magic, it's really hard, but that doesn't mean it's not possible.
gcbirzan 3y ago
In Tavis' blog post he explains it: > In general, if the cores are SMT (Symmetric Multithreading) siblings, then you may observe random branches, and, if they're SMP (Symmetric Multiprocessing) siblings from the same package, then you may observe machine checks. [...] > However, we simply don't know if we can control the corruption precisely enough to achieve privilege escalation. I suspect that it is possible, but we don't have any way to debug μop execution! The exploit they published crashes the machine, but it may be possible to write one that does other things, they just don't know how. Actually useful blog post: https://bughunters.google.com/blog/5997221712101376/the-reptar-cpu-vulnerability https://bughunters.google.com/blog/5997221712101376/the-rept...
- jacquesm 3y ago
  > In Travis' blog post he explains it: Tavis.
  - gcbirzan 3y ago
    Thanks.
saagarjha 3y ago
They produced the processor equivalent of a segfault. Obviously this is a denial of service but it could also mask a more problematic bug lurking behind the scenes.

valenterry 3y ago

I guess it also could 'maybe' lead to people dying... under the right circumstances. In other words: just marketing.

adrian_b 3y ago

It is not an exception. That would have happened if the CPUs had not been buggy. It is a crash that requires a reboot of the computer. Therefore a rogue VM can take down the hypervisor and all the other VMs hosted on the same server. The bug is that according to the x86-64 ISA specification that sequence of instruction prefixes should have caused an illegal instruction exception, but it does not cause any exception. Instead of that, it desynchronizes the microcode execution and the CPU executes other microinstructions than it should, leading into a crash.

danpalmer 3y ago

If you can get the exception thrown only when another process has a particular state, or if that other process's state can affect the timing of the exception throw, then that's information disclosure. Typically these are are hard to pull off, I remember a case a number of years ago where the proof of concept private key exfiltration came months or maybe even a year after the vulnerability was shown, and even then I believe the process took minutes or perhaps hours to run. This stuff isn't magic, it's really hard, but that doesn't mean it's not possible.

gcbirzan 3y ago

In Tavis' blog post he explains it: > In general, if the cores are SMT (Symmetric Multithreading) siblings, then you may observe random branches, and, if they're SMP (Symmetric Multiprocessing) siblings from the same package, then you may observe machine checks. [...] > However, we simply don't know if we can control the corruption precisely enough to achieve privilege escalation. I suspect that it is possible, but we don't have any way to debug μop execution! The exploit they published crashes the machine, but it may be possible to write one that does other things, they just don't know how. Actually useful blog post: https://bughunters.google.com/blog/5997221712101376/the-reptar-cpu-vulnerability https://bughunters.google.com/blog/5997221712101376/the-rept...

jacquesm 3y ago
> In Travis' blog post he explains it: Tavis.
- gcbirzan 3y ago
  Thanks.

saagarjha 3y ago

They produced the processor equivalent of a segfault. Obviously this is a denial of service but it could also mask a more problematic bug lurking behind the scenes.