Wednesday, November 13th 2019
![Intel](https://tpucdn.com/images/news/intel-v1723816949774.png)
Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included
All Intel CPU microarchitectures since 2013 are vulnerable to a new class of "Zombieload," attacks, chronicled under "Zombieload v2" (CVE-2019-11135). This is the fifth kind of microarchitectural data sampling (MDS) vulnerability, besides the four already disclosed and patched against in Q2-2019. The vulnerability was kept secret by the people who discovered it, as Intel was yet to develop a mitigation against it. There is no silicon-level hardening against it, and Intel has released a firmware-level mitigation that will be distributed by motherboard manufacturers as BIOS updates, or perhaps even OS vendors. While Intel's latest enterprise and HEDT microarchitecture, "Cascade Lake" was thought to be immune to "Zombieload," it's being reported that "Zombieload v2" attacks can still compromise a "Cascade Lake" based server or HEDT that isn't patched.
"Zombieload v2" is an exploitation of the Asynchronous Abort operation of Transactional Synchronization Extensions (TSX), which occurs when malware creates read operation conflicts within the CPU. This reportedly leaks data about what else is being processed. "The main advantage of this approach is that it also works on machines with hardware fixes for Meltdown, which we verified on an i9-9900K and Xeon Gold 5218," reads the latest version of the Zombieload whitepaper that's been updated with "Zombieload v2" information. TSX is a requisite for "Zombieload v2," and all Intel microarchitectures since "Haswell" feature it. AMD processors are inherently immune to "Zombieload v2" as they lack TSX. Intel downplayed the severity or prevalence of "Zombieload v2," but dispatched microcode updates flagged "critical" nevertheless.
Source:
ZDNet
"Zombieload v2" is an exploitation of the Asynchronous Abort operation of Transactional Synchronization Extensions (TSX), which occurs when malware creates read operation conflicts within the CPU. This reportedly leaks data about what else is being processed. "The main advantage of this approach is that it also works on machines with hardware fixes for Meltdown, which we verified on an i9-9900K and Xeon Gold 5218," reads the latest version of the Zombieload whitepaper that's been updated with "Zombieload v2" information. TSX is a requisite for "Zombieload v2," and all Intel microarchitectures since "Haswell" feature it. AMD processors are inherently immune to "Zombieload v2" as they lack TSX. Intel downplayed the severity or prevalence of "Zombieload v2," but dispatched microcode updates flagged "critical" nevertheless.
77 Comments on Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included
Sounds like Intel is rather incompetent and care more about their reputation and market position than anything else.
Yes, I know... at that point you've got more problems than a processor exploit.
- Sends a block of data to a program that then causes a buffer overflow that overwrites the program stack of an exploitable program.
- The aforementioned exploit then takes advantage of a privilege escalation which essentially makes whatever malicious code run at a level that's higher than that of the host program.
- Download additional malicious code and execute it.
- ???
- Profit!
This has happened multiple times in everyone's favorite punching bag of a web browser called Internet Explorer! Not a month goes by where we don't read in some security bulletin where there was an issue with memory handling and... well, you get the idea.The whole idea is that you can, at least in theory, line up your exploits in a chain and despite the chain being made up of little pieces, they come together to do much more damage than if they were to be used individually.
Think about Google Chrome, people once said that Google Chrome has an impenetrable sandbox and that nothing can escape it. Yeah... we've seen how that has played out. All it takes is the right exploits put in a chain in the right order and then oh crap, the sandbox has been breached.
Remember, security consulting is literally my day job here.
You'd need an existing ability to execute native code on the system. If you have rdp or even telnet rights, you have that. This is why it's important to trust your users... even with the mitigations.
Frankly, the only claim without evidence is yours. The very sentence of the whitepaper you cite contradicts your claim.
Could theoretically be done with less, but never done it personally.
Mind you, this isn't just theory in my case. I have done this for a client in the past to restore admin rights to a bad-admin firing situation on a cloud server. Gotta love meltdown unmitigated servers.
It is more complex than a point and click attack though. These attacks really only leak data you'd not otherwise know. On it's own, that won't escalate privildges, but there are plenty of other exploits to chain with that that will.
At the end, it needs human involvement. If that's what you mean by physical access, 100% agree.
1. No known attack(successful or otherwise, proof of concept or otherwise) has been documented thus far.
2. While in theory a remote attack is possible, circumstances have to be so very perfect(or be made so) as to be virtually impossible without human input at the target system.
3. Given the difficulty involved, attacks most certainly will require a degree of physical presence at the target system.
4. While the average user is unlikely to have the high levels of security measures implemented that one would find on a business/enterprise system, average users generally do not use the entry points required to render an attack, thus making them effectively protected anyway.
5. Average users, even those targeted by criminal investigations, do not have information valuable enough to justify the difficulty involved in a remote attack attempt(though in practical terms, physical access would be far easier to achieve, assuming such access would be lawful).
6. Rendering attack against power users, such as many of us here at TPU who take personal security very seriously, would make any attempt so extremely unlikely that success is effectively impossible.
7. Attempts will be noticed. An attacker will get 2, maybe 3, attempts before the actions taken to effect such attack will be noticed.
While technically possible, remote exploitation of these types of vulnerabilities is so, ironically, remote as to be effectively impossible without some level of human presence at the target system.
I think this is the original one, might be a repost:
github.com/IAIK/ZombieLoad