• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Intel’s Newest Cascade Lake Chips Hit By New ‘Zombieload’ Flaw

Associate
Joined
9 May 2007
Posts
1,284
The vulnerabilities affect everyone, if you read the research documents back when they first released them it runs via java which means every borwser can be an attack ventor. Also they state they had a proof of concept attack via firefox. They also show a video of stealing browser history etc from a browser and that your location can be stolen over tor and a vpn.

Now things are much worse, they can now steal a hash in seconds and pull off more attacks. The patches that were ment to protect us can't protect us from the developed attacks. They seem to help the attacker.

The latest updates show stealing the AES-NI Key. See 6.1 https://zombieloadattack.com/zombieload.pdf "On average, we recovered the entire AES-128 key of the victim in under 10s using the cache-based trigger and the Dominoattack."

Stealing data from your browser. Keyword Detection and URL Recovery. 6.4 Browsing-Behavior Monitoring " evaluated both attacks running an unmodified Firefox browser version 66.0.2 on the same physical core as the attacker." page 12 "same physical core", I would guess means HT off. Results https://zombieloadattack.com/zombieload.pdf

So that would be your online privacy at risk.
 
Last edited:
Soldato
Joined
15 Jun 2005
Posts
2,751
Location
Edinburgh
The researchers’ JavaScript proof of concept runs externally to the browser using the command line version of the JavaScript engine and uses system tools to ensure core affinity. This is an interesting academic exercise, but it does not then mean that every browser can be an attack vector (any more than it already is). They actually state that they could not make this work inside a modern browser. This is ever more unlikely with the browser mitigations that have been added since.

The video showing stealing of browser history and location is used in a multi-user, VM environment. This is to demonstrate how user A can spy on user B if they are co-hosted on the same physical CPU.

Same physical core does of course not mean HT off. The Zombieload vulnerability relies on HT and understanding this is fundamental to understanding how these attacks can work and when they might be used. Section 6.4 begins by clearly stating that the attack and victim processes are running on sibling logical cores.

The first step in any attack is running some malicious code on your machine. Side channel attacks provide a way of doing this in a multi-user system which “should” have security boundaries. This is irrelevant to a typical home user. Once you have managed to get code running within a home user’s session there is no need to attempt to sample tiny bits data in a hope to find something of value. The system is already owned and the hacker is free to perform much more effective and devastating attacks. The real challenge is getting the victim to run the code.

Your online privacy is at risk far more from Google, Facebook and ISPs than any of these vulnerabilities.
 
Associate
Joined
9 May 2007
Posts
1,284
The researchers’ JavaScript proof of concept runs externally to the browser using the command line version of the JavaScript engine and uses system tools to ensure core affinity. This is an interesting academic exercise, but it does not then mean that every browser can be an attack vector (any more than it already is). They actually state that they could not make this work inside a modern browser. This is ever more unlikely with the browser mitigations that have been added since.

The video showing stealing of browser history and location is used in a multi-user, VM environment. This is to demonstrate how user A can spy on user B if they are co-hosted on the same physical CPU.

Same physical core does of course not mean HT off. The Zombieload vulnerability relies on HT and understanding this is fundamental to understanding how these attacks can work and when they might be used. Section 6.4 begins by clearly stating that the attack and victim processes are running on sibling logical cores.

The first step in any attack is running some malicious code on your machine. Side channel attacks provide a way of doing this in a multi-user system which “should” have security boundaries. This is irrelevant to a typical home user. Once you have managed to get code running within a home user’s session there is no need to attempt to sample tiny bits data in a hope to find something of value. The system is already owned and the hacker is free to perform much more effective and devastating attacks. The real challenge is getting the victim to run the code.

Your online privacy is at risk far more from Google, Facebook and ISPs than any of these vulnerabilities.

Please stop posting non sense. Reread the documents and stick to the evidence, 6 CASE STUDY ATTACKS section for zombieload. "Results. We evaluated both attacks running an unmodified Firefox browser version 66.0.2 (Firefox Release. March 27, 2019) on the same physical core (how the attack works, nothing to do with the non sense IT troll wrote ABSTRACT page 1 Our analysis shows that faulting load instructions (i.e., loads that have to be re-issued) may transiently dereference unauthorized destinations previously brought into the fill buffer by the current or a sibling logical CPU. Hence, despite Intel’s claims [36], we show that the hardware fixes in new CPUs are not sufficient. We discuss both short and long-term mitigation approaches and arrive at the conclusion that disabling hyperthreading is the only possible workaround to prevent at least the most-powerful cross-hyperthread attack scenarios on current processors, as Intel’s software fixes are incomplete.) as the attacker." 6 CASE STUDY ATTACKS page 12 https://zombieloadattack.com/zombieload.pdf

The reason you disable HT is because fill buffers and load ports are shared between HT's. So it's not possible to fully restrict access. https://www.youtube.com/watch?v=Oeb-O4yKK2c 2:38 only safe if HT is disabled and 2:18 When HT is used and why its bad. Source date 14 May 2019.

Remember this new information has just been under embargo. It's just being released now, not found out in the last few months. It's been known from march at least.

From the zombieload.pdf, which you ignore.

"8 CONCLUSION With ZombieLoad, we showed a novel Meltdown-type attack targeting the processor’s fill-buffer logic. ZombieLoad enables an attacker to leak values recently loaded by the current or sibling logical CPU. We show that ZombieLoad allows leaking across user-space processes, CPU protection rings, virtual machines, and SGX enclaves. Furthermore, we show that ZombieLoad even works on MDS- and Meltdown-resistant processors,i.e., even on the newest Cascade Lake micro architecture. We demonstrated the immense attack potential by monitoring browser behavior, extracting AES keys, establishing cross VM covert channels or recovering SGX sealing keys. Finally, we conclude that disabling hyper threading is necessary to fully mitigate ZombieLoad on current processors."
 
Last edited:
Soldato
Joined
15 Jun 2005
Posts
2,751
Location
Edinburgh
Reread the documents and stick to the evidence
This is very good advice and something you should stick to.

The excerpts you quote are completely fine and do not contradict anything I have said. I am not trying to deny these vulnerabilities exist or that a browser (or any other) process can be be attacked. What is often lacking in your posts is the circumstances under which this kind of attack can really be made and would be a viable approach. Go back and re-watch the video you posted from the Red Hat Lead Architect:

"It also requires that an attacker become co-tenant with the target of interest meaning they must be able to run software on the same processor. There are another of number constraints such as being able to run on the same specific core that further complicate a practical attack."

For a typical home user this does not mean, "every borwser can be an attack ventor" (sic), or that their online privacy is at risk, "If your are randomly browsing the internet and going to certain websites" (sic). You are taking elements of the research and inventing your own narrative which simply does not exist and there is no evidence of. Attacking a browser process is not the same as using a browser as an attack vector. This is a fundamental concept.

Of course, people should be generally concerned about their online safety and take appropriate measures. However, these vulnerabilities don't place a home user at any more risk then they already are. Claiming otherwise just comes across as scaremongering.
 
Associate
Joined
9 May 2007
Posts
1,284
This is very good advice and something you should stick to.

The excerpts you quote are completely fine and do not contradict anything I have said. I am not trying to deny these vulnerabilities exist or that a browser (or any other) process can be be attacked. What is often lacking in your posts is the circumstances under which this kind of attack can really be made and would be a viable approach. Go back and re-watch the video you posted from the Red Hat Lead Architect:

"It also requires that an attacker become co-tenant with the target of interest meaning they must be able to run software on the same processor. There are another of number constraints such as being able to run on the same specific core that further complicate a practical attack."

For a typical home user this does not mean, "every borwser can be an attack ventor" (sic), or that their online privacy is at risk, "If your are randomly browsing the internet and going to certain websites" (sic). You are taking elements of the research and inventing your own narrative which simply does not exist and there is no evidence of. Attacking a browser process is not the same as using a browser as an attack vector. This is a fundamental concept.

Of course, people should be generally concerned about their online safety and take appropriate measures. However, these vulnerabilities don't place a home user at any more risk then they already are. Claiming otherwise just comes across as scaremongering.

You have no idea what you are talking about. Your own statements prove you don't. Stop pretending you know crap you clearly don't. Can't you flame and troll elsewhere? Intel CPU are insecure that affects everyone that uses them. Disabling HT reduces the performance to the point even home uses won't buy the CPU's. The document you clearly have not read, clear states that attacks via your browser are possible. That they have carried out such attacks.

Their conclusion states,

"With ZombieLoad, we showed a novel Meltdown-type attack targeting the processor’s fill-buffer logic. ZombieLoad enables an attacker to leak values recently loaded by the current or sibling logical CPU. We show that ZombieLoad allows leaking across user-space processes, CPU protection rings, virtual machines, and SGX enclaves. Furthermore, we show that ZombieLoad even works on MDS- and Meltdown-resistant processors,i.e., even on the newest Cascade Lake micro architecture. We demonstrated the immense attack potential by monitoring browser behavior, extracting AES keys, establishing cross VM covert channels or recovering SGX sealing keys. Finally, we conclude that disabling hyper threading is necessary to fully mitigate ZombieLoad on current processors."

Of interest is, "We demonstrated the immense attack potential by monitoring browser behavior." and also "Results. We evaluated both attacks running an unmodified Firefox browser"

Home users like to browse the internet and attacks via their browser will affect them. Your internet browser runs on your computer, so their attack code will too when your browser runs it. Like stated to you in the other thread, RIDL can be exploited even within restricted sandboxed environments such as JavaScript. Like the JavaScript environment on firefox.

Still you misrepresent how this attack will affect others to the point you disagree with the very documents you are trying to pretend supports your argument. The last time we covered their RIDL javascript attack in another thread where it can run within the browser. Quote "JavaScript attacks To further demonstrate the implications of RIDL, we show that RIDL can be exploited even within restricted sandboxed environments such as JavaScript. We found that we can use WebAssembly in both Firefox and Chrome to generate machine code which we can use to perform RIDL-based attacks" "Despite these challenges, we successfully implemented a proof-of-concept exploit on top of Firefox’ SpiderMonkey JavaScript engine to reliably leak data from a victim process running on the same system" https://mdsattacks.com/files/ridl.pdf page 10. The researchers are not looking to create real world hacking tools, just show that the hard parts can be done.

This is a security hole that is not being closed because of the massive performance hit Intel CPU's will take. Up to 40% reduction once HT is turned off. The only way to mitigate is to turn HT off.
 
Last edited:
Associate
Joined
9 May 2007
Posts
1,284
How much more workarounds in windows because of Intel's incompetence before a Frankenstein windows starts to mess with our Ryzen's?

You are beyond a joke Intel!

Intel were the ones the researchers were focused on, as they had the most market share. AMD could be next as their market share increases. We don't know how well they will do, but for the moment Intel are the most affected by new research.
 
Soldato
Joined
15 Jun 2005
Posts
2,751
Location
Edinburgh
we successfully implemented a proof-of-concept exploit on top of Firefox’ SpiderMonkey JavaScript engine to reliably leak data from a victim process running on the same system
And they go on to say they couldn’t do the same within a modern browser. Attacking a local browser process from a system shell is not the same as using a browser as an attack vector. Please provide any evidence of an MDS attack that can be achieved whilst a home user is “randomly browsing the Internet”. And why an attacker would even use that kind of payload in that scenario.

You have revealed your true agenda in your last post; that Intel owners must disable Hyperthreading and that doing so reduces the CPU performance below an AMD processor. Join us, join us...
 
Caporegime
Joined
17 Mar 2012
Posts
47,662
Location
ARC-L1, Stanton System
And they go on to say they couldn’t do the same within a modern browser. Attacking a local browser process from a system shell is not the same as using a browser as an attack vector. Please provide any evidence of an MDS attack that can be achieved whilst a home user is “randomly browsing the Internet”. And why an attacker would even use that kind of payload in that scenario.

You have revealed your true agenda in your last post; that Intel owners must disable Hyperthreading and that doing so reduces the CPU performance below an AMD processor.

You're arguing with the messenger, the authors of the research clearly say the only way to mitigate is to disable SMT.
 
Associate
Joined
21 Sep 2018
Posts
895
You're arguing with the messenger, the authors of the research clearly say the only way to mitigate is to disable SMT.

This new variant can still leak data even with HT disabled. Just harder to obtain.

https://cyberus-technology.de/posts/2019-11-12-taa.html

You may just be a home user but if you work on your pc then why open yourself or others' data to more risk?

You may be a lawyer, a realtor, a medical practitioner and at same time game on the side.
 
Caporegime
Joined
17 Mar 2012
Posts
47,662
Location
ARC-L1, Stanton System
This new variant can still leak data even with HT disabled. Just harder to obtain.

https://cyberus-technology.de/posts/2019-11-12-taa.html

You may just be a home user but if you work on your pc then why open yourself or others' data to more risk?

You may be a lawyer, a realtor, a medical practitioner and at same time game on the side.

  • Hardware fixes for previous processor vulnerabilities, such as Meltdown or Foreshadow, do not prevent TAA.
  • TAA can leak data on the most recent Cascade Lake CPUs, which are resistant to earlier ZombieLoad variants.
  • The only requirement for the new variant to work is the presence of Intel TSX instructions.
  • By exploiting the CPU’s so-called bypass logic on return values of loads, it is possible to leak data across processes, privilege boundaries, Hyperthreads, as well as values that are loaded inside Intel SGX enclaves, and between VMs.
  • Code utilizing this exploit works on Windows, Linux, etc., as this is not a software- but a hardware issue.
  • Even without Hyperthreading, it is possible to leak data out of other protection domains. During experimentation it turned out, that ZombieLoad leaks endure serializing instructions. Such leaks do however work with lower probability and are harder to obtain.
  • Affected software:
    • So far all versions of all operating systems (Microsoft Windows, Linux, MacOS, BSDs, …)
    • All hypervisors (VMWare, Microsoft HyperV, KVM, Xen, Virtualbox, …)
    • All container solutions (Docker, LXC, OpenVZ, …)
  • Affected CPUs:
    • Intel CPUs with support for Intel TSX (most recent Intel Core and Xeon CPUs).
  • Sole operating system/hypervisor software patches do not suffice for complete mitigation:
    • Similar to the L1TF exploit, effective mitigations require switching off SMT (Simultaneous MultiThreading, aka Hyperthreads) or making sure that trusted and untrusted code do not share physical cores, in addition to any software mitigations that Intel suggests.

Speculation: Data shared between cores or threads is sent through the cache, yes if you don't secure that data it can be siphoned off, securing that data requires extra steps which can slow the system down.
 
Soldato
Joined
18 Aug 2007
Posts
9,710
Location
Liverpool
They have but the researchers appear to have been focusing on Intel at the moment. Just saying that in future AMD might not be so lucky.

To be fair they're 'focusing on Intel at the moment' because every single vulnerability they tested, AMD passed and Intel failed hard... and then Intel's mitigations opened up yet more exploits (which again AMD passed). Let's not pretend it's because nobody looked at AMD properly yet, as that's simply not the case.
 
Caporegime
Joined
17 Mar 2012
Posts
47,662
Location
ARC-L1, Stanton System
They have but the researchers appear to have been focusing on Intel at the moment. Just saying that in future AMD might not be so lucky.

Intel's problem is a fundamental flaw in the architecture and they keep trying to patch it with software in Windows updates, the problem is the flaw in the architecture still exists and with that those testing keep finding new ways to exploit the flaw.
This flaw was never found to exist in AMD's CPU to start with.
 
Associate
Joined
9 May 2007
Posts
1,284
I would say the focus was mostly on Intel because Intel have the biggest market share. At first AMD and Arm were affected. Then because they hit gold with Intel CPU's. I guess they kept investigating Intel. Intel seem to be patching in a whack-a-mole fashion, that is what the researchers appear to be saying. Then embargoing new discoveries for as long as possible. Funny how software companies have to patch their software with mitigations just to keep Intel customers safe. Yet Intel made all the profit and make all the software companies cover the down side of their poor security policies.

I get why people are mad at researchers stating you should disable HT. Basically for home users it turns a 9900k into a 9700k. Yet they are still best for gaming, right? Yet Intel are stating you don't have to turn it off. I wonder why.
 

TNA

TNA

Caporegime
Joined
13 Mar 2008
Posts
27,585
Location
Greater London
I would say the focus was mostly on Intel because Intel have the biggest market share. At first AMD and Arm were affected. Then because they hit gold with Intel CPU's. I guess they kept investigating Intel. Intel seem to be patching in a whack-a-mole fashion, that is what the researchers appear to be saying. Then embargoing new discoveries for as long as possible. Funny how software companies have to patch their software with mitigations just to keep Intel customers safe. Yet Intel made all the profit and make all the software companies cover the down side of their poor security policies.

I get why people are mad at researchers stating you should disable HT. Basically for home users it turns a 9900k into a 9700k. Yet they are still best for gaming, right?
Zen 2 is where it's at right now. Everyone knows this but some wish to lie and cheat themselves. Good luck to them I say.

I don't see Intel coming back until they are on 7nm now. So 2021 or later is my guess. But when they do finally arrive with that tech they may crush AMD like they did with core 2 duo back in the day. Will be interesting to see how it goes.
 
Caporegime
Joined
17 Mar 2012
Posts
47,662
Location
ARC-L1, Stanton System
I would say the focus was mostly on Intel because Intel have the biggest market share. At first AMD and Arm were affected. Then because they hit gold with Intel CPU's. I guess they kept investigating Intel. Intel seem to be patching in a whack-a-mole fashion, that is what the researchers appear to be saying. Then embargoing new discoveries for as long as possible. Funny how software companies have to patch their software with mitigations just to keep Intel customers safe. Yet Intel made all the profit and make all the software companies cover the down side of their poor security policies.

I get why people are mad at researchers stating you should disable HT. Basically for home users it turns a 9900k into a 9700k. Yet they are still best for gaming, right? Yet Intel are stating you don't have to turn it off. I wonder why.

I don't think there is a conspiracy on the part of the researchers here, targeting Intel while ignoring the rest has no benefit to them, it would only damage trust in them, if they were to get anything out of it they would keep the focus and ARM and AMD as well, why just focus on one when there are many more gold mines you could exploit?

As for Intel, they are in full damage control mode, one cannot blame them for that. Intel seem to be under siege from allsorts of angles these days, all of it of their own making, and while i understand their damage control reaction, i have 0 sympathy for them, in fact i would say its karma, they deserve it.
 
Back
Top Bottom