Yet another Intel CPU security vulnerability!

[Twinz]

The main issue I have is if you buy an Intel processor, whats issue can you expect next and what performance the patch will cost you. So far AMD are mostly not affected. I think 8th and 9th gen Intel CPU's are okay with ZombieLoad. That's if you believe Intel.

This is one of the reasons I went with Ryzen. It just feels like future changes to performance for intel stuff is more likley to be a regression (security patches), where Ryzen 3000 stuff is likley to be positive. (Optimizations like the recent ABBA bios)

And yes, I know that ABBA just got boost clocks to "where they should have been" but I bought mine with the old bios/boost clock performance as the benchmark.

 

[Rroff]

The ZombieLoad attack allows stealing sensitive data and keys while the computer accesses them.

While programs normally only see their own data, a malicious program can exploit the fill buffers to get hold of secrets currently processed by other running programs. These secrets can be user-level secrets, such as browser history, website content, user keys, and passwords, or system-level secrets, such as disk encryption keys.

The attack does not only work on personal computers but can also be exploited in the cloud.

https://zombieloadattack.com/
ZombieLoad in Action CVE-2018-12130
In our demo, we show how an attacker can monitor the websites the victim is visiting despite using the privacy-protecting Tor browser in a virtual machine.

https://www.pcgamesn.com/intel/zomb...y-patch-hyperthreading-mitigation-performance

“We conclude that disabling hyperthreading, in addition to flushing several microarchitectural states during context switches, is the only possible workaround to prevent this extremely powerful attack,” a research paper describing the Zombieload flaw, authored by researchers at Graz University of Technology, Cyberus Technology, Worcester Polytechnic Institute, and KU Leuven, says.

https://mdsattacks.com/
RIDL and Fallout: MDS attacks CVE-2018-12126, CVE-2018-12127, CVE-2019-11091

The RIDL and Fallout speculative execution attacks allow attackers to leak private data across arbitrary security boundaries on a victim system, for instance compromising data held in the cloud or leaking your data to malicious websites. Our attacks leak data by exploiting the 4 newly disclosed Microarchitectural Data Sampling (or MDS) side-channel vulnerabilities in Intel CPUs. Unlike existing attacks, our attacks can leak arbitrary in-flight data from CPU-internal buffers (Line Fill Buffers, Load Ports, Store Buffers), including data never stored in CPU caches. We show that existing defenses against speculative execution attacks are inadequate, and in some cases actually make things worse. Attackers can use our attacks to leak sensitive data despite mitigations, due to vulnerabilities deep inside Intel CPUs.

RIDL
RIDL (Rogue In-Flight Data Load) shows attackers can exploit MDS vulnerabilities to mount practical attacks and leak sensitive data in real-world settings. By analyzing the impact on the CPU pipeline, we developed a variety of practical exploits leaking in-flight data from different internal CPU buffers (such as Line-Fill Buffers and Load Ports), used by the CPU while loading or storing data from memory.

We show that attackers who can run unprivileged code on machines with recent Intel CPUs - whether using shared cloud computing resources, or using JavaScript on a malicious website or advertisement - can steal data from other programs running on the same machine, across any security boundary: other applications, the operating system kernel, other VMs (e.g., in the cloud), or even secure (SGX) enclaves.

Fallout
Fallout demonstrates that attackers can leak data from Store Buffers, which are used every time a CPU pipeline needs to store any data. Making things worse, an unprivileged attacker can then later pick which data they leak from the CPU's Store Buffer.

We show that Fallout can be used to break Kernel Address Space Layout Randomization (KASLR), as well as to leak sensitive data written to memory by the operating system kernel.

Ironically, the recent hardware countermeasures introduced by Intel in recent Coffee Lake Refresh i9 CPUs to prevent Meltdown make them more vulnerable to Fallout, compared to older generation hardware.


https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190013

These vulnerabilities are known as:

• • CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling (MSBDS) 
  • CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling (MFBDS)
  • CVE-2018-12127 - Microarchitectural Load Port Data Sampling (MLPDS)
  • CVE-2019-11091 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM)

To be fully protected, customers may also need to disable Hyper-Threading (also known as Simultaneous Multi Threading (SMT)).

Potential performance impacts
Specific performance impact varies by hardware generation and implementation by the chip manufacturer. For most consumer devices, impact on performance may not be noticeable. Some customers may have to disable Hyper-Threading (SMT) to fully address the risk from MDS vulnerabilities. In testing Microsoft has seen some performance impact with these mitigations, in particular when hyperthreading is disabled. Microsoft values the security of its software and services and has made the decision to implement certain mitigation strategies in an effort to better secure our products. In some cases, mitigations are not enabled by default to allow users and administrators to evaluate the performance impact and risk exposure before deciding to enable the mitigations. We continue to work with hardware vendors to improve performance while maintaining a high level of security.

Mitigation strategies

Intel has provided CPU microcode updates, and recommendations for mitigation strategies for operating system (and hypervisor) software. See Intel's Security Advisory for more details. We recommend you install the software updates provided by your operating system and/or hypervisor vendor.

In addition, we recommend disabling Simultaneous Multi-Threading (SMT), also known as Intel® Hyper-Threading Technology, which significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations. Note that you might still be vulnerable despite disabling SMT, as MDS does not strictly rely on the presence of SMT.

Not quite sure if that was posted in relation to my post but while not a perfect analogy disabling hyper-threading on the average home user desktop is a bit like locking the stable after the horse has bolted - by the time that vulnerability comes into play you have already been owned. If people are worried enough that they are disabling HT they'd be better off selling up and swapping to a Ryzen based system.

Obviously a different situation where you are directly exposed to people able to access a system directly to run code such a VPS where it could be used to snoop beyond security boundaries and break outside of sandboxing, etc.

 

[LoadsaMoney]

Another day, another Intel security flaw.

 

[Boot_Loop]

Looks like a major issue this one.

I want to see Ryzen 3000 CPUs benched against an Intel system with most (not even all) of the mitigations installed and see how much the Intel system loses perf.

Unfortunately nearly all reviewers use numbers from when the 8700K, 9900K etc were released, when these SKUs werent patched to high heaven with performance slowing mitigations.

 

[Jimmy Weirdarms]

Not quite sure if that was posted in relation to my post but while not a perfect analogy disabling hyper-threading on the average home user desktop is a bit like locking the stable after the horse has bolted - by the time that vulnerability comes into play you have already been owned. If people are worried enough that they are disabling HT they'd be better off selling up and swapping to a Ryzen based system.

Obviously a different situation where you are directly exposed to people able to access a system directly to run code such a VPS where it could be used to snoop beyond security boundaries and break outside of sandboxing, etc.

I'm not saying "Disable HT now!", but even that description of RIDL there talks about rogue advertising being able to perform these attacks from Javascript. You don't have to have been 'owned' for someone to serve you a dodgy ad that does this stuff, just stumble upon the wrong website.

It's almos t like running arbitrary, unchecked code grabbed at random from the internet isn't the best idea....

 

[Rroff]

I'm not saying "Disable HT now!", but even that description of RIDL there talks about rogue advertising being able to perform these attacks from Javascript. You don't have to have been 'owned' for someone to serve you a dodgy ad that does this stuff, just stumble upon the wrong website.

It's almos t like running arbitrary, unchecked code grabbed at random from the internet isn't the best idea....

It is a bit counter-intuitive but these kind of attacks can't simply be used against an indiscriminate target via malicious ads - although that approach can work against a known target environment if browser mitigations aren't used. Browser mitigations also give robust protection against any trivial use of these vulnerabilities so if people are browsing without such mitigations they have bigger problems in the first place. Also as noted on the site having HT on isn't a pre-requisite for these exploits to work it just makes it easier for the attacker. (We are talking more in terms of skipping a step rather than making it harder in a useful way).

 

[Jimmy Weirdarms]

It is a bit counter-intuitive but these kind of attacks can't simply be used against an indiscriminate target via malicious ads - although that approach can work against a known target environment if browser mitigations aren't used. Browser mitigations also give robust protection against any trivial use of these vulnerabilities so if people are browsing without such mitigations they have bigger problems in the first place. Also as noted on the site having HT on isn't a pre-requisite for these exploits to work it just makes it easier for the attacker.

Browser mitigations are a good thing, undeniably, but it's not great that they're needed. I suppose arguably they are exactly where the mitigations should be - they are the piece that asks us to trust them with the ability to retrieve and execute arbitrary code most often.
Regardless, I don't think it's as simple as "HT good" or "HT bad", just to acknowledge that some of these attacks can happen through the browser and are therefore applicable to home users to. The RIDL authors make the point that the attacks may point to systemic problems in design and design complexity of CPUs, so there may be others out there not yet mitigated. Personally I think we need a revolution in the browser-dev space when it comes to running untrusted JS...

 

[Rroff]

Browser mitigations are a good thing, undeniably, but it's not great that they're needed. I suppose arguably they are exactly where the mitigations should be - they are the piece that asks us to trust them with the ability to retrieve and execute arbitrary code most often.
Regardless, I don't think it's as simple as "HT good" or "HT bad", just to acknowledge that some of these attacks can happen through the browser and are therefore applicable to home users to. The RIDL authors make the point that the attacks may point to systemic problems in design and design complexity of CPUs, so there may be others out there not yet mitigated. Personally I think we need a revolution in the browser-dev space when it comes to running untrusted JS...

Agreed on the not as simple as "good", "bad".

Comes back to what I said a few posts back that if people are that worried about HT then they should seriously consider changing from Intel.

 

[zx128k]

Basically disabling HT on its own is not enough but really helps. To be secure you have to disable HT and patch. Both are required at the same time. The hit of disabling HT is so bad, you have to consider taking the risk of leaving HT enabled. Basically securing the 9900k from all the security issues in hardware leaves the cpu slower than the 3800x. From the other patches it's already lost 28% of it performance.

 

[Rroff]

Basically disabling HT on its own is not enough but really helps

The only place disabling HT does anything material to protect you is in some kind of shared/server environment especially involving virtual machines where someone could log into a VPS and use these kind of weaknesses to snoop outside of the domain their processes are running in.

Disabling HT really does very little materially to help you if you are the average home user - something needs to have already penetrated your system to make use of the HT weaknesses and if something has got itself running on your system there are far easier ways it can gather data from you, etc. by the point it gets to that you have already been owned. It is also for the most part very hard to use these side-channel attacks against an indiscriminate target making them less useful for your average fire and forget malware that targets general desktop users - but very powerful for someone who is trying to purposefully intrude in a specific system such as a server. (Side-channel attacks are basically a process of "sounding" things out until you have enough information to form a complete picture).

If the cocktail of uncertainty over Intel's security has you disabling HT as a precaution then you really need to be moving away from Intel in either case.

EDIT: Besides which some of the newer vulnerabilities superseded stuff like Portsmash in usefulness at doing the same thing anyhow without requiring HT/SMT.

 

[zx128k]

The only place disabling HT does anything material to protect you is in some kind of shared/server environment especially involving virtual machines where someone could log into a VPS and use these kind of weaknesses to snoop outside of the domain their processes are running in.

Disabling HT really does very little materially to help you if you are the average home user - something needs to have already penetrated your system to make use of the HT weaknesses and if something has got itself running on your system there are far easier ways it can gather data from you, etc. by the point it gets to that you have already been owned. It is also for the most part very hard to use these side-channel attacks against an indiscriminate target making them less useful for your average fire and forget malware that targets general desktop users - but very powerful for someone who is trying to purposefully intrude in a specific system such as a server. (Side-channel attacks are basically a process of "sounding" things out until you have enough information to form a complete picture).

If the cocktail of uncertainty over Intel's security has you disabling HT as a precaution then you really need to be moving away from Intel in either case.

Basically any code that runs on the CPU can be a threat. HT makes securing the CPU much harder, basically patches in software can help provide mitigation strategies when not running HT. Fixing HT on top of this requires much more effort. That's why you are told, "Disabling HT significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations." Basically the CPU is completely insecure, they can provide mitigation strategies but HT adds a level of complexity on top that which would require a more complex mitigation. Basically the CPU does not handle data securely and HT makes the problem more complex to fix. They recommend disabling Simultaneous Multi-Threading (SMT) as it is the easiest or only way to solve the security whole at the moment in software. Disabling HT is not a precaution or something to do just in case. HT on = insecure. HT off and patches help secure the CPU as a whole. Basically your computer browse is an attack vector, so this affects everyone. The fixes for the other security wholes have made this one easier to exploit too, so you have to fix that as well. This is a hardware problem that can only be truly fixed by new hardware. https://www.zdnet.com/article/beyond-spectre-foreshadow-a-new-intel-security-problem/

This is why I am AMD at the moment.

Intel CPU 8700k,
https://mdsattacks.com/images/mdstool.png

AMD CPU 3800x
https://ibb.co/X2Tq8Z1

Intel CPU affected
https://software.intel.com/security...-enumeration-and-architectural-msrs#MDS-CPUID

 

[Rroff]

Basically any code that runs on the CPU can be a threat. HT makes securing the CPU much harder, basically patches in software can help provide mitigation strategies when not running HT. Fixing HT on top of this requires much more effort. That's why you are told, "Disabling HT significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations." Basically the CPU is completely insecure, they can provide mitigation strategies but HT adds a level of complexity on top that which would require a more complex mitigation. Basically the CPU does not handle data securely and HT makes the problem more complex to fix. They recommend disabling Simultaneous Multi-Threading (SMT) as it is the easiest or only way to solve the security whole at the moment in software. Disabling HT is not a precaution or something to do just in case. HT on = insecure. HT off and patches help secure the CPU as a whole. Basically your computer browse is an attack vector, so this affects everyone. The fixes for the other security wholes have made this one easier to exploit too, so you have to fix that as well. This is a hardware problem that can only be truly fixed by new hardware.

Most of which is only applicable in a server type environment. HT on/off makes no material difference to your likelihood of being compromised as a home user unless you are running things like virtual machines people can log into remotely and I pretty much guarantee that if someone comes up with a viable way to use these side-channel attacks against the average home user that disabling HT will provide zero effectiveness in preventing it (look at the whitepaper on RIDL for instance).

There are already other newer weaknesses that can get the same end result anyhow even with HT off - at this point having HT on just means a would be attacker can skip a step at most.

Potentially HT can be addressed at OS level by white listing how processes are setup on available cores/threads so for instance games by well known publishers could be allowed to fully use HT resources while unknown applications were isolated to a specific core, etc.

Note that Intel recommend it as an optional step for certain environments.

Once these updates are applied, it may be appropriate for some customers to consider additional steps. This includes customers who cannot guarantee that trusted software is running on their system(s) and are using Simultaneous Multi-Threading (SMT). In these cases, customers should consider how they utilize SMT for their particular workload(s), guidance from their OS and VMM software providers, and the security threat model for their particular environment. Because these factors will vary considerably by customer, Intel is not recommending that Intel® HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS.

 

[zx128k]

Most of which is only applicable in a server type environment. HT on/off makes no material difference to your likelihood of being compromised as a home user unless you are running things like virtual machines people can log into remotely and I pretty much guarantee that if someone comes up with a viable way to use these side-channel attacks against the average home user that disabling HT will provide zero effectiveness in preventing it.

There are already other newer weaknesses that can get the same end result anyhow even with HT off - at this point having HT on just means a would be attacker can skip a step at most.

Potentially HT can be addressed at OS level by white listing how processes are setup on available cores/threads so for instance games by well known publishers could be allowed to fully use HT resources while unknown applications were isolated to a specific core, etc.

Again home users are effected, you can be attack via your browser. Given that there is example code in the wild. It's just a matter of time. HT has to be disable and the system patched. Both need to happen. This is a mitigation strategy as the hardware cannot be fixed. The website provided have videos showing an attack via a browser which is used by most home users. Turning HT off is the biggest step in the mitigation strategy. I no longer have this hardware problem as I have moved to AMD. I used to be a i7 4930k overclocked to 4.5Ghz with DDR3 - 2400 ram. That processor is just as insecure as the i7 4820k you have. The real fix to all these problems, Intel admits, is by replacing today's processors.

 

[Rroff]

Again home users are effected, you can be attack via your browser. Given that there is example code in the wild. It's just a matter of time. HT has to be disable and the system patched. Both need to happen. This is a mitigation strategy as the hardware cannot be fixed. The website provided have videos showing an attack via a browser which is used by most home users. Turning HT off is the biggest step in the mitigation strategy. I no longer have this hardware problem as I have moved to AMD. I used to be a i7 4930k overclocked to 4.5Ghz with DDR3 - 2400 ram. That processor is just as insecure as the i7 4820k you have.

That browser/javascript example only works against a specific target - you can't just leave a malicious ad up and indiscriminately compromise every system exposed to it if their side-channel attack mitigations aren't sufficient. If you read the whitepaper on the latest exploits they don't depend on SMT so disabling HT won't provide any mitigation anyhow if anyone ever does find a way to put them to use against home users.

 

[zx128k]

That browser/javascript example only works against a specific target - you can't just leave a malicious ad up and compromise every system exposed to it. If you read the whitepaper on the latest exploits they don't depend on SMT so disabling HT won't provide any mitigation anyhow if anyone ever does find a way to put them to use against home users.

There are malicious ads all the time. The demo on one website is the proof of concept of putting it to use against a home user. HT makes mitigation a lot harder. I use mitigation because you can't fix the issue. To mitigate you have to turn HT off AND then patch the software. There is no way to mitigate with HT on at the moment. You have to do a security audit before leaving HT on. The problem is the CPU hardware which cannot be fixed. I quote again, "In addition, we recommend disabling Simultaneous Multi-Threading (SMT), also known as Intel® Hyper-Threading Technology, which significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations." Security on Intel CPU's is crap and it costs you most of the performance advantage over AMD in trying to mitigate the issue. Once Intel fixes the issue I may buy Intel CPU's again.

 

[Rroff]

There are malicious ads all the time. The demo on one website is the proof of concept of putting it to use against a home user.

If it was as simple as crafting a malicious ad and boom you could pull privileged information in any useful way from processes running on the PC of a percentage of indiscriminate viewers they'd be all over the web by now. If you read the latest version of the whitepaper SMT is not required for this attack and turning it on or off provides no useful mitigation.

I quote again, "In addition, we recommend disabling Simultaneous Multi-Threading (SMT), also known as Intel® Hyper-Threading Technology, which significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations."

That was generic advice given the variety of scenarios covered on the site - they also note:

"Note that you might still be vulnerable despite disabling SMT, as MDS does not strictly rely on the presence of SMT."

The real threat is in environments where a would be attacker can arbitrarily execute code such as a VPS - this also removes any requirement for setting up a feedback channel, etc. to do anything useful for instance:

We also verified that SGX enclaves are vulnerable to our cross-process attacks when SMT is enabled, allowing an attacker on the same physical core to leak SGX-initiated reads and writes to memory. We built SGX enclaves in pre-release mode (with debugging disabled), and successfully reproduced the cross-process experiments. Our proof-of-concept exploit trivially leaks reads and writes from a victim enclave running on a sibling hardware thread.

Then there is other vulnerabilities including stuff like NetCat (albeit that one is restricted to network activity) which turning HT off doesn't really do anything to mitigate anyhow if anyone ever finds a way to use them - most of these side-channel attacks have to be crafted specifically for the individual target with some kind of knowledge of the specific target environment in advance or otherwise at best there is just too much "noise" to make any sense of data they do manage to leak.

 

[zx128k]

If it was as simple as crafting a malicious ad and boom you could pull privileged information in any useful way from processes running on the PC of a percentage of indiscriminate viewers they'd be all over the web by now. If you read the latest version of the whitepaper SMT is not required for this attack and turning it on or off provides no useful mitigation.



That was generic advice given the variety of scenarios covered on the site - they also note:

"Note that you might still be vulnerable despite disabling SMT, as MDS does not strictly rely on the presence of SMT."

The real threat is in environments where a would be attacker can arbitrarily execute code such as a VPS - this also removes any requirement for setting up a feedback channel, etc. to do anything useful for instance:



Then there is other vulnerabilities including stuff like NetCat (albeit that one is restricted to network activity) which turning HT off doesn't really do anything to mitigate anyhow if anyone ever finds a way to use them - most of these side-channel attacks have to be crafted specifically for the individual target with some kind of knowledge of the specific target environment in advance or otherwise at best there is just too much "noise" to make any sense of data they do manage to leak.

Just read one of the white papers (RIDL), with smt or ht enabled the attack always works. Was fig 3. The secret always leaked but the attack often still works without smt or ht turned on.

"Unaware of the source of our initial RIDL leaks, wedis covered that they originate from the LFBs, rather than from other processor state, by conducting several experiments on a workstation featuring an Intel Corei7-7700K (Kaby Lake). For our experiments, we use a kernel module to mark memory pages in our victim thread as write-back(WB),write-through(WT),write-combine(WC) and uncacheable(UC) [42], [43]. We use Intel TSX to implement the attack for our analysis and perform 10;000 rounds to leak the data during every run of the experiment. Furthermore, we run every experiment 100 times and report the average."

Fig. 3: In each pair of bars, one bar shows the LFB hit count,and the other one the number of attacks. With SMT, we always leak the secret. Without SMT and no victim code, RIDL only reads zeros, but with victim and attacker in the same hardware thread, we still leak the secret in most cases (top/red bar), while occasionally finding the value the CPU should have loaded.

The next white paper for fallout at the end, Leaks can only occur when the security domain changes within a hyperthread. Only latest generation Coffee Lake R machines are vulnerable to the attack

"Flushing-Based Countermeasures. Because the store buffer is not shared across hyperthreads, leaks can only occur when the security domain changes within a hyperthread. Thus, flushing the store buffer on security domain change is sufficient to mitigate the attack. In particular, we verified that using mfenceas part of the switch from kernel mode to user mode thwarts the attack.

Limitations. As mentioned above, the attacks described in Section 4 are unable to leak information across hyperthreads. Moreover, as Meltdown software countermeasures (KPTI) flush the buffer on leaving the kernel, and as the store buffer is automatically flushed on change of the CR3 register (i.e., on context switch), only latest generation Coffee Lake R machines are vulnerable to the attack described in Section 4. Ironically, the hardware mitigations present in newer generation Coffee Lake R machines make them more vulnerable to Fallout than older generation hardware"

No wonder they advise turning off HT.

 

[Rroff]

Just read one of the white papers (RIDL), with smt or ht enabled the attack always works. Was fig 3. The secret always leaked but the attack often still works without smt or ht turned on.

"Unaware of the source of our initial RIDL leaks, wedis covered that they originate from the LFBs, rather than from other processor state, by conducting several experiments on a workstation featuring an Intel Corei7-7700K (Kaby Lake). For our experiments, we use a kernel module to mark memory pages in our victim thread as write-back(WB),write-through(WT),write-combine(WC) and uncacheable(UC) [42], [43]. We use Intel TSX to implement the attack for our analysis and perform 10;000 rounds to leak the data during every run of the experiment. Furthermore, we run every experiment 100 times and report the average."

Fig. 3: In each pair of bars, one bar shows the LFB hit count,and the other one the number of attacks. With SMT, we always leak the secret. Without SMT and no victim code, RIDL only reads zeros, but with victim and attacker in the same hardware thread, we still leak the secret in most cases (top/red bar), while occasionally finding the value the CPU should have loaded.

The next white paper for fallout at the end, Leaks can only occur when the security domain changes within a hyperthread. Only latest generation Coffee Lake R machines are vulnerable to the attack

"Flushing-Based Countermeasures. Because the store buffer is not shared across hyperthreads, leaks can only occur when the security domain changes within a hyperthread. Thus, flushing the store buffer on security domain change is sufficient to mitigate the attack. In particular, we verified that using mfenceas part of the switch from kernel mode to user mode thwarts the attack.

Limitations. As mentioned above, the attacks described in Section 4 are unable to leak information across hyperthreads. Moreover, as Meltdown software countermeasures (KPTI) flush the buffer on leaving the kernel, and as the store buffer is automatically flushed on change of the CR3 register (i.e., on context switch), only latest generation Coffee Lake R machines are vulnerable to the attack described in Section 4. Ironically, the hardware mitigations present in newer generation Coffee Lake R machines make them more vulnerable to Fallout than older generation hardware"

No wonder they advise turning off HT.

But then you have to put it into context - some of those techniques are only applicable to when you have an executable running (usually requiring someone in manual control of it to do anything useful) and aren't applicable to script vulnerabilities, etc. some are more of a threat to certain environments than others due to their nature. Problem is people are taking a lot of the information at face value usually just as mud to sling at Intel with little interest in understanding what it is actually about - granted breaking it down into a more technical deep dive would be beyond a post here.

 

[zx128k]

Basically with HT on you can steal data from any thread but with it off, you can only steal data from the same thread.

 

[Rroff]

Basically with HT on you can steal data from any thread but with it off, you can only steal data from the same thread.

But that isn't applicable to any and every side-channel attack and in many cases on the average consumer desktop there are other vulnerabilities once a piece of malicious software is at the point of being able to abuse HT (or more critically before it gets to that point) that make far easier and more useful mechanisms for the attacker. (Usually in these environments the "attacker" is fire and forget malware - side-channel attacks aren't well suited to this use and more powerful a tool in the hands of someone intent on manually breaking into a specific target).

Where HT really makes a difference is in situations where it allows a hands on attacker the ability to break out of what should be secure software domains - allowing them to snoop across boundaries they shouldn't.