Critical Flaws in Computers Leave Millions of PCs Vulnerable

Windows: Attack on Bitlocker via TPM Borncity.com | March 15, 2019

​

Windows Bitlocker encryption is not foolproof. Now a new attack method on Bitlocker encryption over the TPM chip has become known. But needs access to a notebook or computer...

 

Just don’t use WinRAR, OK? Askwoody.com | March 17, 2019

I’ve been trying to avoid this topic, but it now appears to be engulfing the blogosphere.

If you use WinRAR, you were suckered. I’ve never recommended it. But if for some reason you’ve installed it — or even paid for it — uninstall it and get something worthwhile (and free!) like 7-Zip or one of a dozen alternatives.

@mn- posted about WinRAR’s security problems back in February, when they were discovered and disclosed. Martin Brinkmann had thorough coverage on ghacks. It all has to do with an ancient archiving format called ACE, and the “19-year-old” security hole is being exploited right now. McAfee says they’ve found “over 100 unique exploits and counting,” but I think they’re double-dipping. Catalin Cimpanu on ZDNet has a recent accounting.

WinRAR devs released WinRAR 5.70 Beta 1 on January 28 to address this vulnerability, however, users have to manually visit the WinRAR site, download and then install it. The vast majority of users are most likely unaware that this vulnerability even exists, let alone that they need to install a critical security update.​

Tempest, meet teapot. But if you have WinRAR for some bizarre reason, get rid of it.

 

Never used it anyway but lately I have seen many people using 2009 or 2012 version on Win 10 (Technically it was W7/8.1 forced upgrade to 10)

 

'ShadowHammer' infects Asus PCs through its Asus Live Update utility pcworld.com | March 25, 2019
Kaspersky Lab confirmed that perhaps a million Asus PCs have unwittingly downloaded an infected version of the Asus Live Update utility.

"Over 57,000 users, and possibly up to a million, have downloaded and installed a version of the Asus Live Update utility that was poisoned with a backdoor and hosted on the official Asus servers."

We've reached out to Asus for comment, and will update this story when we hear back.

What this means for you: Given that Asus is usually considered to be the fifth-largest PC vendor in the world, and that ShadowHammer used authentic certificates, the attack is significant. Fortunately, you’re unlikely to be a target. The earlier ShadowPad triggered the download of malware only if a target was considered “interesting,” and it’s likely your PC isn’t. Still, if you’re concerned, Asus Live Update can apparently be safely uninstalled: Asus describes the process here, though it can be performed normally though Windows as well.

----------------------------------------

Hackers Get to ASUS Live Update Servers, Plant Malware in Thousands of Computers Techpowerup.com
In a chilling reminder of just why system software should always be manually updated and never automatically, Vice Motherboard citing Kaspersky Labs reports that hackers have compromised the Live Update servers of ASUS, making them push malware to thousands of computers configured to fetch and install updates automatically. These include not just PC motherboards, but also pre-builts such as notebooks and desktops by ASUS. Smartphones and IoT devices by ASUS are also affected. Hackers have managed to use valid ASUS digital certificates to masquerade their malware as legitimate software updates from ASUS.

Kaspersky Labs says that as many as half a million devices have fallen prey to malware pushed to them by ASUS. The cybersecurity firm says it discovered the malware in January 2019 when implementing a new supply-chain detection technology, and informed ASUS by late-January. Kaspersky even sent a technically-sound representative to meet with ASUS in February. Kaspersky claims that ASUS has since been "largely unresponsive since then and has not notified ASUS customers about the issue." ASUS is already drowning in bad-rep from the PC enthusiast community for its Armoury Crate feature that lets motherboard BIOS push software to a Windows installation through an ACPI table dubbed "the vendor's rootkit," which ASUS enabled by default on new motherboards. Who knows what recent motherboard BIOS updates have pushed into your PC through this method.

 

Yep, I don't use any "Live Update" features, I could install a Live Update program from my motherboard manufacturer (MSI, not Asus), but chose not to, I just update manually.

 

Asus Challenges Kaspersky's Operation ShadowHammer Numbers
by Tomshardware.com | March 26, 2019

ASUS Releases Fix For Live Update Shadowhammer Backdoor Malware Attack Hothardware.com
ASUS goes on to clarify that the backdoor only affected its notebooks running earlier versions of Live Update. The company has also made available a security diagnostics tool that scans your system to determine if you’ve been backdoored [ Download Link]. If the diagnostic tool determines that you were targeted, ASUS recommends that you back up your files and restore your PC to its factory default settings.

I neither do live updates from Micro$h4fts Win Update. Always manual install of patches. You risk malware from all places if you allow automatic updates

 

It's easy enough to track down the latest version package from the vendor site + other newer models updates + OEM updates.

Who wants to get a bunch of "surprises" auto-installed, only to find 1/2 of them aren't the newest and the other 1/2 are items you've already uninstalled.

It can be said it's nice to see the auto-update options, see the items and version numbers to then be motivated to seek out the newest versions on the product pages, but I'd rather just go to the product pages - newest products support pages first thing.

 

Even hashes or checksums are important too.
I always get few surprises from WU so I disabled it permanently!

 

Microsoft Discovers Backdoor-Like Flaw In Huawei Matebook Driver Tomshardware.com | March 26, 2019
Microsoft security researchers discovered a security flaw in Huawei’s device manager driver for the Matebook line of Windows 10 PCs that could undermine low-level kernel protections, not unlike the WannaCry backdoor the NSA developed and then was leaked to the public. The news comes at the heels of Huawei being accused by the U.S. government and other governments of being an espionage arm for the Chinese government. ZDNet first reported the news.

 

The title for Huawei is a bit misleading since it was discovered and patched by January.

 

Backdoor: ASUS had been warned about risks for months
Published on March 28, 2019 by Günter Born

​

Two months before it was revealed that the ASUS Live Update Utility had been compromised and backdoored, security researchers had warned the computer manufacturer about it. Because they had come across unbelievable sloppiness.

Probably Micro$h4ft that hunted after some better publicity. After everything thats went wrong with their latest and greatest tragedy... They really needed it.

 

Intel Chipsets' Undocumented Feature Can Help Hackers Steal Data
by Lucian Armasu March 29, 2019 at 9:50 AM - Source: Positive Technologies

The bad news is that the Positive Technologies researchers found a way to disable VISA using an older Intel ME vulnerability. Intel released a firmware patch that fixes that vulnerability back in 2017, but unless your laptop maker or motherboard maker has sent your the updated firmware and you updated your system with it, your PC will remain vulnerable. This bug can’t be fixed through operating system updates.

 

Researcher Reveals Multiple Flaws in Verizon Fios Routers — PoC Released
https://thehackernews.com/2019/04/verizon-wifi-router-security.html


A cybersecurity researcher at Tenable has discovered multiple security vulnerabilities in Verizon Fios Quantum Gateway Wi-Fi routers that could allow remote attackers to take complete control over the affected routers, exposing every other device connected to it.

 

Interesting, how safe are the majority of routers out there being used by households from attacks & hacks? I'm not talking this specific router, but in general? Does changing the admin password & disabling remote log on prevent the majority of the attacks/hacks. There's got to be a lot of old routers out there, I wonder at what point they become unsafe to use? (Not just questions for you, anyone.)

 

If/when the manufacturer stops releasing updated firmware for known fixes, toss it away. Netgear is one of the worst for abandoning currently sold (and otherwise usable) routers when a new model is released.

Changing the admin user name and the password to at least a dozen, random, characters is a good start. As is making sure that UPnP and WAN access is disabled too. Port forwarding is also something most users don't need. Even with the garbage Xbox and other gaming consoles 'instructions' available on the web.

There is much more to make a network secure, but for home users, making sure of the above makes them safer than 99.9999% of the rest of the users out there.

With all this said, the most common way that a network is compromised (even the router itself) is when an outsider's device is allowed on it.

NEVER, EVER allow anything other than the equipment you own and control on your network. Wired, especially, but WiFi connections too (even on most home routers weak 'guest' networks). Most people think that wired, main WiFi and guest WiFi are three different connects. They're not.

 

Razer's laptops confirmed to be affected by critical vulnerability
Razer issued fixes for all the models launched from 2016 onward, but owners of the Blade and Blade Pro models released prior to 2016 will have to wait for a few more weeks to get the fixes. The vulnerability is identical to the ea...

 

Or deploy two different models in a row; would be an off-chance if both are vulnerable to some exploit or another. Yet so, then a three-in-a-row setup would make such a possibility pretty much negligible.

Another consideration for such a setup is that even if a device is within warranty, receives adequate, ongoing support and has no known vulnerabilities then that still does not necessarily mean it is a safe, secured device; after all, it is usually discouraged to inform the owners you're trespassing on their property.

Or flash any other custom, diy bios version, of course. So ...

 

I believe that all kind of BIOS's from all vendors has something inside to hack you in cooperation for the benefit of their governments. No escape except you are a highly skilled developer and you can create your own.

 

Not so much bioses I'd be worried about; there's too many people working on them to keep such nefariousnesses a secret for long. Intel, AMD and networking systems are quite another thing; nicely concentrated and system-dependency is nearly total.

That Huawei debacle is just silly; if you don't trust them to supply clean devices then simply insist on schematics and firmware access. PCBs aren't some magic, black boxes wherein arcane dark arts are taking place; if it isn't on the board and in the software then those backdoors and loggers simply aren't there. And the sums necessary to roll out 5G aren't a pittance, so why needlessly limit your choice of vendors when locking up a few nerds in a shed for a few weeks together with the devices and code is all it takes to safe several of those billions?

There is one reason you might think of; those in charge of spending these sums aren't necessarily the most technologically astute (are they ever?), so gut-feeling and hearsay may well play a bigger factor than do cold logic and hard data.

 

That still won't work, for the issue, I mentioned above.

Worse, the double and triple NAT'd nature of the network is now compromising usability (or, ports will then need to be opened anyway, between the routers). I would think that the performance (latency) of the network will suffer too, as the ISP speeds continually increase, the older (any current) routers simply can't keep up.

The best way to continue using them is probably just as an AP. The best way to continue having the best performance is to get the current model AP's instead.

 

The article has a few things wrong, the Apple CVE number is CVE-2018-4251, and the Razer bug discovered in February is an Intel Management Engine Manufacturing Mode bug over a year old. Here's a more accurate article:

Razer issues fix for well-known Intel ME firmware vulnerability
Problem was discovered in Blade models in February but has existed in Intel motherboards for at least a year
By Cal Jeffrey on April 8, 2019, 3:14 PM
https://www.techspot.com/news/79557-razer-issues-fix-well-known-intel-firmware-vulnerability.html

" Why it matters: Razer’s has finally addressed a security vulnerability in its Blade gaming laptops. The flaw was discovered in some Intel-based computers last year. The security risk can allow malware to burrow deep into the system.

The flaw, listed as CVE-2018-4251, was initially discovered on Apple laptops prior to macOS 10.13.5. The vulnerability involves Intel’s ME Manufacturing Mode, which is part of the motherboard firmware. Apple found and patched the security hole last year.

However, last month security researcher Bailey Fox publicly reported the flaw persists in Razer computers. After struggling for over a month privately through HackerOne to get the company to acknowledge the problem, Fox took to Twitter to get the company’s attention.

"After trying for a month to get this dealt with via HackerOne, I'm bringing this public," Fox said. "All current Razer laptops are shipped in Intel Manufacturing Mode, and have full R/W on the SPI flash. This is a direct repeat of CVE-2018-4251. This is still not fixed."

Hey! Thanks for mentioning us. Our Systems Team would like to check on this. Could you please tell us more about the challenges with your Razer laptop via DM and we'll take it there.
— RΛZΞR Support (@RazerSupport) March 21, 2019

The move worked as Razer’s support team quickly responded asking Fox to describe the problem in a private direct message.

Manufacturing Mode is used by Intel for configuring settings like boot verification. If left open, malware can take control, setting up the system to allow other vulnerabilities like Meltdown to be exploited. Worse yet, malware and configurations can be burned to the firmware allowing it to go undetected by anti-virus software, as well as allowing it to persist after formatting the hard drive or performing a factory reset. There is no end user use for Manufacturing Mode, so it should not even be included in the mobo firmware.

Last week, Razer acknowledged the problem and has issued a fix.

“Razer has been alerted to certain Intel Management Engine vulnerabilities in the Intel chipsets of several Razer laptop models,” a spokesperson told The Register. “To address this issue, Razer laptops will ship from the factory with an update to remove these vulnerabilities. For currently shipped products, Razer has provided a software tool to apply this update.”

The affected devices include several Blade models. If you currently own a Razer laptop, you should check out the company’s step-by-step manual on the issue, which also contains a link to the patch."

 

How do you find out if the manufacturer has stopped releasing updates for the router? It could be that the router never required any BIOS updates, or for example maybe only one BIOS update close to release date or something - in that case how do you know when the manufacturer has stopped supporting that model?

For that last point, that's an interesting one - flashing custom BIOS. Do you mean DD-WRT? https://www.flashrouters.com/learn/router-basics/what-is-dd-wrt
I don't have any experience with that, although I have just googled it just now, and it looks like my exact router model is not supported:
https://dd-wrt.com/support/router-database/
Thing is those custom BIOS aren't guaranteed or don't have the latest security updates do they?

 

Routers don't really require any BIOS updates (even though some manufacturers call them that) what should be continually be patched is their O/S (firmware) and the Linux packages they include with them and depend on to reliably run.

Just like a Windows system frozen in time, it will eventually be open to more and more exploits as time goes on. If continuous updates are not issued for the firmware on any specific model on a regular basis.

Depending on which version/fork of DD-WRT (and others) is used, will depend on how up-to-date it is patched with regards to security. Most are miles ahead than stock firmware from most of the consumer/prosumer lineups. Even otherwise solid systems like robust pfSense setups are able to be caught off guard with certain exploits (from within and from without) an otherwise secure/locked down network. Many such exploits make the news.

Here is one site that keeps track of CVE's:

See:
https://www.cvedetails.com/vendor/16/Cisco.html


If I see a commercial router without a firmware update within a quarter (and there are known/discovered issues for similar models/OS's/chipsets), I would be immediately shopping for a new router. If I didn't already have one or more in testing, waiting to be deployed.

I don't take security for granted. I don't expect the manufacturer to hold my hand either. I make it a point to regularly check for such updates and may even implement some of them myself (if possible), while I wait for the official response, from the hardware vendor of my choice. How regularly I check and take my networked computers off-line is proportional to the risk potential of the exploit I want to minimize. And they are off-line a lot.

(Test, verify, test again, rinse and repeat a few more times, only then, turn on the internet pipe).

Anything I need to get done online at that point I have a few options (i.e. different locations, w/different network topology, from different vendors + WAN/LAN chipsets) to choose from. And I take advantage of that fully. Cellular/Satellite connects have come in handy at times.

The best systems for online security are ones which you roll on your own. Code every line, lock down every exception and do it twice and three times over. Yeah, even at the cost of and usually in spite of mere convenience and maximum performance 'scores' for the network being protected. The security here doesn't come from merely exceptional programming/networking skills. It comes from the fact that it is designed, created and used in a way that as a whole, it can't be bought, dissected and/or analyzed. And that makes it exponentially more secure than any well-known system out there, no matter what the cost and purported security such a commercial system may offer.

I've stated many times in these forums that if I put mine or my client's data on an HDD/SSD, it never leaves my control. Not for warranty, not for refunds, not for any reason. (I'll hand one over, just give me a minute and a hammer and I'll give you some data-dust).

The processes, systems, and networks are even more protective of that data.

 

Thanks very much for that cvedetails link! I checked the list of products on there, and it doesn't list my router, is that because they don't list all routers (I've got TP link) - they do list TP link but not my model - does that mean there are no security vulnerabilities discovered for it yet or they've not listed it for other reasons? TP-Link seem to be quite secure according to that website, and of the few tp-link products I clicked on it was showing as "Remote" being the means of infection - and I'm thinking if you have remote management disabled then you're good to go. I see the value of what you're saying about checking that website for vulnerabilities & then seeing if your router is covered. My last firmware update was late 2016, and that's the initial release of the firmware.

I spoke through online text chat with TP-Link support just now, to find out if my router is still supported/considered re firmware security updates - they say it is. I did ask them where I could look in the future to see if it's supported or not & they couldn't provide me with an adequate answer - I got the impression they just wanted to end the chat because they didn't know! They gave me conflicting information, first they gave me a link just to the front page of the tp link website, and then when I laughed at that they gave me a link to the tplink forums. It was nigh on possible to find out from those forums if a model is supported or not. TP Link need to provide better & more transparent info about which models of router are phased out & end of life.

You are far more security conscious than me, but it does seem that you need to be in your line of work - I'm just a home user. What business are you in for your clients, and it's ok if you don't want or can't say?

(EDIT: found a complete listing of TP link products on that CVEdetails website, my router still not listed).

EDIT#2: Yeah, pretty much all of the vulnerabilities are accessed through remote management: https://www.cvedetails.com/vulnerab...&sha=35781d9525571cd66feb101a1896e97c0bad1d33

 

Intel MEI?

 

I bought a cheap netgear dual band router and it was already out since 2 years. Once I heard it was affected by KRACK, I emailed Netgear asking if there was a fix and the rep said they were working on it and all models will receive the patches. In fact they updated the firmware with KRACK fixes and solved peformance issues. Rep from netgear said there's 5 yr of security FW updates regardless of any models even on EOL list. I even have a 2 yr warranty active on the router though 90 day phone/email premium support has ended.

 

That's good. Yes, my next router purchase I'll research to find one that has good support as well as a compatibility with open source firmwares like DD-WRT, which extends the life/functionality too.

 

You're welcome. The link I provided doesn't necessarily list all models.

I don't deal with TP-Link, their products are not on my radar. Of the consumer routers currently available, Asus has certain models that stand out. They (Asus) have come amazingly far in such a short time in this relatively new, to them, field.

If I had a router that was last updated in 2016, I would be buying all new devices that have ever touched my network (or at the very least securely doing a fresh/clean O/S install on each one). It does seem that TP-Link is following in Netgear's footsteps by abandoning their devices when an upgraded/new model comes along too. That response from 'support' is another reason for me to drop that router, if not the whole company for my routing needs.

And me? I'm just a photographer.

Well, maybe a bit more than just that.


See:
https://arstechnica.com/information...lnerable-to-hacks-that-steal-wi-fi-passwords/


The link above shows why security isn't something that is one and done. Now, the hackers are already able to break future tech.

This is why you don't believe marketing, buzzwords and other, over-the-top hype. Because that is all it is until proven otherwise. Most of the time, the proof never comes (at least, nowhere close to the date of introduction of the product/service/process/etc.).

It is also why you don't leave a working setup for a 'better' one either. Not without testing in parallel and long term, in your actual, not 'estimated', or 'close enough', usage. And that's when you're considering another option that has been available for 'forever', already. With all its known quirks and issues.

With a newborn tech? Step lightly, you're most likely to sink. Fast, and out of control too.

I'll repeat that warranty and lipservice 'support' and other such nonsense doesn't mean squat.

And once more I'll repeat the best security possible is don't be online (or have your data/devices/etc.) online if you don't have to. Yeah, and there is very little you can't do without having your data online with you too.

 

Yeah, I probably won't buy another T-P Link router. I'd want one which is compatible with that open source firmware we were talking about - to extend the life. I'd probably also buy one from a company that is clear on how long they support their models for - in terms of updates.

You're way more security conscious than me, I'm gonna keep my router for the time being for example, I do use strong passwords though, switch off remote management & Plug & Play.

 

Major flaw discovered using Internet Explorer to snoop or steal files


How to remove Internet Explorer 11 from Windows 7 and Windows 10 PCs

 

Yet Another Speculative Malfunction: Intel Reveals New Side-Channel Attack, Advises Disabling Hyper-Threading Below 8th, 9th Gen CPUs Techpowerup.com | May 14, 2019

Ouch doesn't even begin to describe how much that headline hurt. As far as speculatrive execution goes, it's been well covered by now, but here's a refresher. Speculative execution essentially means that your CPU tries to think ahead of time on what data may or may not be needed, and processes it before it knows it's needed. The objective is to take advantage of concurrency in the CPU design, keeping processing units that owuld otherwise be left idle to process and deliver results on the off-chance that they are indeed required by the system: and when they are called for, the CPU saves time by not having to process them on the fly and already having them available.

The flaws have been announced by intel in coordination with Austrian university TU Graz, Vrije Universiteit Amsterdam, the University of Michigan, the University of Adelaide, KU Leuven in Belgium, Worcester Polytechnic Institute, Saarland University in Germany and security firms Cyberus, BitDefender, Qihoo360 and Oracle. While some of the aprts involved have named the four identified flaws with names such as "ZombieLoad", "Fallout", and RIDL, or "Rogue In-Flight Data Load", Intel is taking the PEGI-13 Microarchitectural Data Sampling (MDS) name.

 

I have a feeling this is more applicable to cloud server PC's, because Microsoft have released some patches for this but the protections are only activated on Windows 10 Server (IIRC from reading the patch release notes yesterday). There are still easier ways for attackers to steal data, so I think these exploits are mostly gonna be used in very specific targeted high value attacks (e.g. cloud servers). That's my impression, so I'm not about to disable hyperthreading.

 

I have to wonder. Since the 8th and 9th gen CPU's are supposedly ok it means now there is a great reason to upgrade. This creates a huge pool of systems to be replaced at a time where there is little CPU enhancement to demand an upgrade reason.

 

New Zombieload + Fallout + RIDLx2 Updates posted here:

http://forum.notebookreview.com/thr...atches-and-more.812424/page-124#post-10910951

http://forum.notebookreview.com/thr...atches-and-more.812424/page-123#post-10910928

http://forum.notebookreview.com/thr...atches-and-more.812424/page-123#post-10910828

 

I don't think there is a safe Intel CPU yet, some of the mitigations are included in the new generation, but not all of the vulnerabilities are patched.

Intel has previously said to disable HT for other vulnerabilities, so disbling HT is still a standing recommendation from Intel.

Intel's HT comments specifically for Zombieload + Fallout + RIDLx2 is that disabling HT *won't* completely solve it.

This statement from Intel that disabling HT doesn't solve Zombieload + Fallout + RIDLx2 shouldn't be taken to suggest we leave HT on in general.

Intel isn't being forward informing about what is still not mitigated in the 8th / 9th gen in each piece of advertising that mentions those new CPU's solve some issues, but Intel doesn't list what they haven't fixed.

We shouldn't lull ourselves into thinking that Intel has solved the Intel CPU architecture vulnerabilities issues in the 8th and 9th gen, Intel haven't done this yet. Intel have only moved some microcode fixes over into the CPU hardware, but the matching OS patches are still needed.

Intel needs to come out with a complete re-architecture for their CPU's - computationally different - not "chipletting" or "FOVOSing" the same design. That's simply re-architecting the physical implementation, not re-architecting the currently flawed computational methodology.

So far I haven't seen Intel mention anything in those new breakup's of function to "improve" implementation to indicate that these changes are being done as security vulnerability solutions.

 

https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

Is Intel recommending that I disable HT?
No. Intel is not recommending that users disable Intel® Hyper threading. It’s important to understand that doing so does not alone provide protection against MDS, and may impact workload performance or resource utilization that can vary depending on the workload.

Well according to their public statement from today, they are in fact not recommending you disable HT. Alone doing that does not provide protection. Instead you need to update windows and likely wait for further patching. I've already done the update from Windows myself and according to the MDS website I have patched against certain vulnerabilities or am "not affected". This is of course with a 9900K. "Certain" 8th and 9th gen are not susceptible to these vulnerabilities. More importantly these exploits are not easy to pull off like previous exploits. According to Intel's documentation "Exploiting MDS outside the controlled conditions of a research environment is a complex undertaking and Intel is not aware of any reported real-world usage of these security issues".

https://www.pcworld.com/article/3395439/intel-hyper-threading-zombieload-cpu-exploit.html

Intel: You don't need to disable Hyper-Threading to protect against the ZombieLoad CPU exploit

Have we heard of a single case of Spectre or Meltdown in the wild? I haven't seen a single documented case. This is a similar exploitation/situation and we will likely never see or hear of a single case in the wild after patching occurs. It's definitely not an ideal situation, but knowing that 8th and 9th gen already have hardware fixes, we can be somewhat assured going forward that most hardware will no longer offer the same level of exploitation. Fix it, learn from it, and move on. Nothing and no company is perfect. The silver lining for Intel is that out of this they have refined and reformed their hardware security department. Hardware exploitation is a relatively new field and Intel will absolutely tighten the screws going forward.

 

Apple's Zombieload + Fallout + RIDLx2 mitigation recommendations include disabling HT (hyperthreading):

How to enable full mitigation for Microarchitectural Data Sampling (MDS) vulnerabilities
This option is available for macOS Mojave, High Sierra, and Sierra after installing security updates.
https://support.apple.com/en-us/HT210108

Spoiler

"Intel has disclosed vulnerabilities called Microarchitectural Data Sampling (MDS) that apply to desktop and notebook computers with Intel CPUs, including all modern Mac computers.

Although there are no known exploits affecting customers at the time of this writing, customers who believe their computer is at heightened risk of attack can use the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology, which provides full protection from these security issues.

This option is available for macOS Mojave, High Sierra and Sierra and may have a significant impact on the performance of your computer.

Performance impact of disabling hyper-threading
The full mitigation, which includes disabling hyper-threading, prevents information leakage across threads and when transitioning between kernel and user space, which is associated with the MDS vulnerabilities for both local and remote (web) attacks.

Testing conducted by Apple in May 2019 showed as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks.

Performance tests are conducted using specific Mac computers. Actual results will vary based on model, configuration, usage, and other factors.

How to enable full mitigation for MDS in macOS
To enable full mitigation of MDS after installing security updates, start your Mac in macOS Recovery and then enter commands in the Terminal app.

1. Turn on or restart your Mac and immediately press and hold Command (⌘)-R or one of the other macOS Recovery key combinations on your keyboard.
2. From the Utilities menu in the menu bar, choose Terminal.
3. Type the following two commands, one at a time, at the Terminal prompt. Press Return after each one.
   nvram boot-args="cwae=2"
   
   nvram SMTDisable=%01
   
   
4. From the Apple menu , choose Restart.

How to revert the mitigation and reenable hyper-threading
To revert the mitigation and reenable hyper-threading processor technology, reset NVRAM and restart your Mac.

If you previously set custom boot-args, you will need to add those boot-args to the nvram command.

Note: The full mitigation is not enabled while using Boot Camp to run Windows on a Mac.

How to check the status of hyper-threading in macOS
You can check if hyper-threading is enabled or disabled in the System Information app.

Choose Apple menu  > About This Mac, then click the System Report button. Then select Hardware in the sidebar. If the processor in your Mac supports hyper-threading, Hyper-Threading Technology is shown as either Enabled or Disabled.

Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Risks are inherent in the use of the Internet. Contact the vendor for additional information. Other company and product names may be trademarks of their respective owners.
Published Date: May 14, 2019

Intel ZombieLoad flaw forces OS patches with up to 40% performance hits
JEREMY HORWITZ @HORWITZ MAY 14, 2019 11:58 AM
https://venturebeat.com/2019/05/14/...es-os-patches-with-up-to-40-performance-hits/

"When security researchers disclosed a series of major vulnerabilities impacting Intel processors back in January 2018, it was clear that “Meltdown” and “Spectre” were indeed serious — and wouldn’t be the only exploits of multi-threading chips.

Now a new Intel chip vulnerability nicknamed “ ZombieLoad” has been revealed to the public, and though it’s already being patched by three major operating system makers, there’s some bad news: full protection could reduce your CPU’s performance by up to 40%.

Spoiler

Referred to by the more technical name “Microarchitectural Data Sampling,” the ZombieLoad exploit enables an attacker to access privileged data across trust boundaries. In a cloud hosting environment, it could enable one virtual machine to improperly access information from another; researchers also showed that it could be used for app surveillance and password acquisition. The vulnerability broadly impacts operating systems that run on Intel chips, including Android, Chrome, Linux, macOS, and Windows.

In a just-published support document, Apple suggests that full ZombieLoad mitigation will require Intel chip users to disable Intel’s hyper-threading processing feature — a major selling point of the chipmaker’s CPUs. During testing this month, Apple says that it found “as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks,” though actual performance impacts will vary between machines.

Because of that steep performance drop, Apple has implemented a partial mitigation in macOS Mojave 10.14.5, leaving users to decide whether they want to disable hyper-threading for full protection. If so, the support document provides Terminal commands to turn the feature off and on, notably including a requirement that the machine boot in recovery mode to disable the chip feature.

Google and Microsoft (via TechCrunch) have also started the process of patching their Intel-based operating systems. In Google’s case, Chrome OS devices have already received some protections and will receive more in the next OS release; Intel-only Android devices are rare, but will receive OS patches once device makers deploy them. Microsoft is releasing patches for Windows today, and has already protected Azure users. Some microcode processor updates will come from Microsoft directly, and others from device makers.

The ZombieLoad issue was apparently disclosed to Intel one month ago, and impacts all Intel processors produced since 2011. Chips from AMD and ARM are not believed to be susceptible to this flaw. According to vendors, there are no known real-world exploits of the vulnerability at this point, though the researchers simply say that they don’t know if it’s been abused in the wild.

Update at 12:45 p.m. Pacific: An Intel page discussing the vulnerabilities downplays the performance impacts, suggesting that the performance impact is small: up to 3% without disabling hyper-threading, and up to 8-9% with hyper-threading disabled, though included charts show tinier changes using the latest, high-end Intel Core i9-9900K processors.

Intel underscores that disabling hyper-threading isn’t really necessary for some users: consequently, unless it’s necessary for a given customer’s workloads and security environment, it says that it’s “not recommending that Intel HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS.”

 

Chrome OS 74 disables CPU hyperthreading to mitigate Intel vulnerabilities
May 14, 2019 Kevin C. Tofel
https://www.aboutchromebooks.com/ne...threading-intel-mds-vulnerabilities-security/

"If you’ve noticed your Chromebook performance to be a little slower with Chrome OS 74, it’s could be due to a change in how your Chromebook handles CPU hyperthreading. More precisely, Chrome OS 74 disables CPU hyperthreading to mitigate security risks due to Microarchitectural Data Sampling (MDS) vulnerabilities.

Google has a Chrome OS support page with full details, but here’s the key aspect:

" Microarchitectural Data Sampling (MDS) is a group of vulnerabilities that allow an attacker to potentially read sensitive data. If Chrome processes are attacked, these sensitive data could include website contents as well as passwords, credit card numbers, or cookies. The vulnerabilities can also be exploited to read host memory from inside a virtual machine, or for an Android App to read privileged process memory (e.g. keymaster).

To protect users, Chrome OS 74 disables Hyper-Threading by default. For the majority of our users, whose workflows are primarily interactive, this mitigates the security risk of MDS without a noticeable loss of responsiveness. Chrome OS 75 will contain additional mitigations."

If you want the details on MDS, you can read more about the vulnerabilities at their respective pages here: CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091. Keep in mind if you have an ARM processor in your Chromebook, you’re not affected.

This kind of response, while unfortunate, is probably the best way to handle open vulnerabilities. And to be clear: They don’t apply simply to Chromebooks: They apply to any computer or device running on an Intel processor.

And frankly, while it may not be obvious to Chromebook device users if their machine is using hyperthreading for a particular use, typical usage likely doesn’t take advantage of hyperthreading anyway. In which case, there’s either a minimal or no impact.

While I don’t recommend it, you can re-enable hyperthreading on your Chrome OS device by browsing to chrome://flags#scheduler-configuration and enabling the “performance” setting."

 

So far it looks like all of the OS vendors recommend disabling SMT / HT as part of the Intel MDS mitigations...here's Ubuntu's wiki instructions for Intel MDS:

Microarchitectural Data Sampling (MDS)
CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091
It was discovered that memory contents previously stored in microarchitectural buffers of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core via a speculative execution side-channel.

A local attacker could access the stale contents of store buffers, load ports, and fill buffers which may contain data belonging to another process or data that originated from a different security context.

As a result, unintended memory exposure can occur between userspace processes, between the kernel and userspace, between virtual machines, or between a virtual machine and the host environment.

MDS differs from other recent speculative execution side-channel attacks in that the attacker cannot target specific data.

The attacker can periodically sample the contents in the buffers but does not have control over the data that is present in the buffers when the sample is taken.

Therefore, additional work is required to fully collect and reconstruct the data into a meaningful data set.

Processors from other vendors are not known to be affected by MDS. [Intel only vulnerability]

Spoiler: Click for more details...

Four CVEs have been assigned to cover different variations of the data sampling flaw:

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

This document will refer to the general set of data sampling flaws as MDS. The specific acronym will be used when referring to one of the individual data sampling flaws, such as MFBDS.

Mitigations
Intel has provided microcode updates which, in conjunction with updated kernels, mitigate the vulnerabilities in some situations. The underlying technique used to remediate all four issues is the same. The kernel executes a specific instruction which causes all affected microarchitectural buffers to be cleared. The kernel must execute the instruction at different times for each data sampling vulnerability. In some situations, clearing the buffers will prevent adversaries from accessing the data that was present.

The kernel and corresponding intel-microcode package updates fully address the MDS flaws if your processor does not support Hyper-Threads, also known as Symmetric Multi-Threading (SMT).

MDS is not fully mitigated if your processor supports Hyper-Threads and Hyper-Threads are enabled.

Ubuntu recommends disabling Hyper-Threads on affected systems if the system is used to execute untrusted or potentially malicious code. Some example workloads that warrant the need to disable Hyper-Threads are:

• A multi-user system with a potentially malicious user. A malicious user could leverage MDS to extract secrets from other users on the system.
• A system that runs programs which come from questionable sources. This could occur if a user on the system regularly makes use of new versions of programs that are published by an individual or group that they don't fully trust. A malicious software publisher could leverage MDS to extract secrets from the system.
• A system that hosts virtual machines from varying security domains and/or that the system owner does not fully trust. A malicious program in one virtual machine could extract secrets from other virtual machines or from the virtualization host itself.

Please see the Configuration section below for configuration details, including how to disable Hyper-Threads.

The upstream Linux kernel community is working on process scheduling improvements that may allow existing systems with Hyper-Thread support to be fully mitigated against MDS attacks. The changes are referred to as Group, or Core, scheduling. The Ubuntu kernel may support such scheduling changes in a future release.

IMPORTANT: There is no software fallback mechanism available for processors that have not received microcode updates from Intel. Mitigation is only possible if Intel has provided a microcode update for your processor.

Updates
Ubuntu users are recommended to update to the latest kernel, intel-microcode, and qemu packages. The majority of users should ensure that the following kernel packages are installed:

Ubuntu Release Base Kernel Enablement Kernel

19.04
linux-image-5.0.0-15-generic 5.0.0-15.16
N/A

18.10

linux-image-4.18.0-20-generic 4.18.0-20.21

N/A

18.04 LTS

linux-image-4.15.0-50-generic 4.15.0-50.54

linux-image-4.18.0-20-generic 4.18.0-20.21

16.04 LTS

linux-image-4.4.0-148-generic 4.4.0-148.174

linux-image-4.15.0-50-generic 4.15.0-50.54

14.04 ESM

linux-image-3.13.0-170-generic 3.13.0-170.220

linux-image-4.4.0-148-generic 4.4.0-148.174

12.04 ESM

linux-image-3.2.0-140-generic 3.2.0-140.186

linux-image-3.13.0-140-generic 3.13.0-140.186

Users of other Ubuntu kernels should consult the Ubuntu Security Notices for specific version information.

Due to the complexity of the changes involved in mitigating this hardware vulnerability, a livepatch will not be available via the Canonical Livepatch Service.

Ubuntu users with Intel processors should ensure that the following intel-microcode packages are installed:

Release

intel-microcode Version

19.04

intel-microcode 3.20190514.0ubuntu0.19.04.1

18.10

intel-microcode 3.20190514.0ubuntu0.18.10.1

18.04 LTS

intel-microcode 3.20190514.0ubuntu0.18.04.2

16.04 LTS

intel-microcode 3.20190514.0ubuntu0.16.04.1

14.04 ESM

intel-microcode 3.20190514.0ubuntu0.14.04.1

12.04 ESM

Not available; please consult your hardware vendor's website for a BIOS update containing new microcode


Ubuntu users with Intel processors that use KVM virtualization should also ensure that the following qemu packages are installed:

Release

qemu Version

19.04

qemu 1:3.1+dfsg-2ubuntu3.1

18.10

qemu 1:2.12+dfsg-3ubuntu8.7

18.04 LTS

qemu 1:2.11+dfsg-1ubuntu7.13

16.04 LTS

qemu 1:2.5+dfsg-5ubuntu10.38

14.04 ESM

qemu 2.0.0+dfsg-2ubuntu1.46

Ubuntu users with Intel processors that use libvirt to manage KVM virtualization should also ensure that the following libvirt packages are installed:

Release

libvirt Version

19.04

libvirt 5.0.0-1ubuntu2.1

18.10

libvirt 4.6.0-2ubuntu3.5

18.04 LTS

libvirt 4.0.0-1ubuntu8.10

16.04 LTS

libvirt 1.3.1-1ubuntu10.26

Configuration

MDS Configuration
MDS mitigation is enabled by default after booting the system with updated kernel and intel-microcode packages. In this configuration, MDS attacks are fully prevented if the processor does not support Hyper-Threads.

The following kernel boot option can be used to disable Hyper-Threads of affected processors. This configuration provides full mitigation on updated systems:

mds=full,nosmt

IMPORTANT: Whilst the above is provided as a generic solution to disable Hyper-Threads, instead it is recommended to disable Hyper-Threads in your BIOS settings rather than disabling them with the kernel boot option. The processor will not need to dedicate certain resources to multiple threads within a single processor core when Hyper-Threads are disabled in the BIOS. This could result in a small performance improvement when compared to disabling Hyper-Threads in the kernel.

MDS mitigation does incur some performance overhead. You may use the following kernel boot option to disable MDS mitigations entirely:

mds=off

IMPORTANT: Vulnerability mitigations should only be disabled in carefully controlled environments where all of the code being executed is known and trusted. Disabling any of these mitigations in situations where untrusted code can be executed is not recommended.

Please see the Linux kernel MDS Admin Guide for more information on configuration options.

General CPU Mitigation Configuration
A new boot option is included in the updated kernels that mitigate MDS. The new option allows the system administrator to configure all CPU vulnerability mitigations with a single option.

The following kernel boot option can be used to enable all mitigations and disable Hyper-Threads for processors affected by L1TF and/or MDS:

mitigations=auto,nosmt

CPU side-channel mitigations do incure some performance overhead. You may use the following kernel boot option to disable all mitigations:

mitigations=off

IMPORTANT: Vulnerability mitigations should only be disabled in carefully controlled environments where all of the code being executed is known and trusted. Disabling any of these mitigations in situations where untrusted code can be executed is not recommended.

Please see the Linux Kernel Parameters Admin Guide for more information on the mitigations= kernel boot option.

Checking System Status
Updated Ubuntu kernels have the ability to report how the system is currently affected by MDS. To check your system, read the contents of the:

/sys/devices/system/cpu/vulnerabilities/mds file.

You must apply kernel updates and reboot if the file does not exist as that indicates that your kernel does not have mitigations in place for MDS.

Processors that aren't vulnerable to MDS will report the following:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Not affected

You may encounter a situation where you have an updated Ubuntu kernel but you don't have updated microcode. This could occur if you've not updated to the latest intel-microcode package or if Intel has not released new microcode for your processor. You'll see the following in this situation:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable

Processors that have Hyper-Threading support enabled will indicate that SMT is vulnerable:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

The file will contain the following contents for processors that do not support Intel Hyper-Threading or where Hyper-Threading has been disabled:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT disabled

The kernel is unable to reliably determine whether Hyper-Threading is enabled when running in a virtual environment. Updated host kernel packages, updated host qemu packages with proper configuration to pass through the host CPU type to the guest, and updated guest kernel packages will show the following status inside of the virtual environment:

$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT Host state unknown

The examples above cover the most common situations. Please see the Linux Kernel MDS Admin Guide for additional, less common situations.

References
For more information on these issues, please see the following reference documents:

• Intel Security Advisory INTEL-SA-00233
  
  
• Intel MDS Overview
  
  
• Intel MDS Deep Dive
  
  
• Intel Developer Guidance for MDS
  
  
• Linux kernel MDS Admin Guide
  
  
• Linux kernel MDS Technical Information

Timeline

• 2019 May 14 at 17:00 UTC: the issue is made public

Here's an article announcing when OpenBSD gave up on Intel SMT / HT, defaulting to disabled, about a year ago...

OpenBSD Disabling SMT / Hyper Threading Due To Security Concerns
Written by Michael Larabel in Linux Security on 19 June 2018 at 05:41 PM EDT. 35 Comments
https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-Disabling-SMT

"Security oriented BSD operating system OpenBSD is making the move to disable Hyper Threading (HT) on Intel CPUs and more broadly moving to disable SMT (Simultaneous Multi Threading) on other CPUs too.

Disabling of Intel HT and to follow with disabling SMT for other architectures is being done in the name of security. " SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core."

OpenBSD could improve their kernel's scheduler to workaround this, but given that is a large feat, at least for now they have decided to disable Hyper Threading by default.

Those wishing to toggle the OpenBSD SMT support can use the new hw.smt sysctl setting on OpenBSD/AMD64 and is being extended to cover CPUs from other vendors and architectures.

This may have a large impact on multi-threaded workloads, but OpenBSD developers are trying to play this down by saying, " Note that SMT doesn't necessarily have a positive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores."

The change was merged today ahead of the eventual OpenBSD 6.4 release."

 

RIP Hyper-Threading? ChromeOS axes key Intel CPU feature over data-leak flaws – Microsoft, Apple suggest snub
Plug pulled on SMT tech as software makers put security ahead of performance
By Thomas Claburn in San Francisco 14 May 2019 at 21:14
https://www.theregister.co.uk/2019/05/14/intel_hyper_threading_mitigations/

" Analysis - In conjunction with Intel's coordinated disclosure today about a family of security vulnerabilities discovered in millions of its processors, Google has turned off Hyper-Threading in Chrome OS to fully protect its users.

Meanwhile, Apple, Microsoft, IBM's Red Hat, QubesOS, and Xen advised customers that they may wish to take similar steps.

The family of flaws are dubbed microarchitecture data sampling (MDS), and Chipzilla's official advisory is here, along with the necessary microcode updates to mitigate the data-leaking vulnerabilities and list of affected products. Installing these fixes and disabling Intel's Hyper-Threading feature is a sure fire way to kill off the bugs, though there may be a performance hit as a result.

Spoiler: Long... tldr; Disable SMT/HT

Background
Hyper-Threading is Intel's implementation of simultaneous multithreading (SMT), a technique for splitting a single physical processor core into two virtual cores known as hardware threads. It's supposed to improve performance by allowing two software threads to run simultaneously through each physical core, sharing available resources on the silicon as needed. This means one physical core can juggle two threads, either in the same application or two separate applications, at the same time, improving throughput. Some workloads benefit from this, some are hindered or see no gain. You mileage may vary.

However, one thing it does bring into the mix is the risk that side-channel surveillance techniques, such as MDS, may be able to break hardware thread isolation, and access sensitive data it shouldn't be able to see. In other words, one thread can snoop on the memory accesses of another thread sharing the same physical CPU core, and lift passwords, keys, and other secrets, potentially.

Really, today's chip flaw disclosures cover a group of design blunders: ZombieLoad (CVE-2018-12130) can be exploited by malware or rogue users on a vulnerable system to potentially steal browser histories, website content, user keys, passwords, and system-level secrets, such as disk encryption keys from other parts of memory.

We're told it can work across CPU protection rings and process boundaries, and against cloud and on-premises virtual machines and trusted execution environments. Proof-of-concept exploit code is available to try it out for yourself.

There's also RIDL and Fallout (CVE-2018-12126, CVE-2018-12127, CVE-2019-11091) that can be exploited to steal confidential info from memory.

Mitigating these security oversights in Intel's chips will require microcode updates to be installed, and operating system and hypervisor patches to utilize them, so check your OS vendor, and system manufacturer if needed, for new software and install it as soon as you're able. These fixes may introduce a performance hit depending on what kind of programs you're running.

You can opt to turn off Hyper-Threading to fully neutralize the threat, though you may want to weigh up if it's worth the performance cost by testing your applications with the feature on and off.

Google
Google said it is disabling Hyper-Threading by default in Chrome OS 74, citing security concerns, and noting that Chrome OS 75 will have additional mitigations.

" The decision to disable or enable Hyper-Threading is a security versus performance tradeoff," said the web giant's people in a vulnerability notice. "With Hyper-Threading disabled, Intel CPUs may experience reduced performance, which varies depending on the workload. But, with Hyper-Threading enabled, users could execute code, such as by visiting a website or running an Android app, that exploits MDS to read sensitive memory contents."

Google has further details on how it's handling the bugs, from its client applications to cloud services, right here.

BSD land
The OpenBSD community, for one, came to that conclusion last year when it disabled Hyber-Threading in OpenBSD 6.4. In response to past Intel processor vulnerabilities (TLBleed and L1TF) that showed Hyper-Threading to be a risk, OpenBSD leader Theo de Raadt observed that Hyper-Threading is fundamentally broken because shares resources between two CPU instances without assuring secure isolation.

"DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS," he said in a mailing list post at the time.

Apple
Apple has released macOS Mojave 10.14.5 to address MDS attacks via JavaScript and Safari. [Apple] says a comprehensive fix requires turning off Hyper-Threading, which comes with a potentially substantial performance cost.

" Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology," Apple warned in its advisory. "This capability is available for macOS Mojave, High Sierra, and Sierra in the latest security updates and may reduce performance by up to 40 per cent, with the most impact on intensive computing tasks that are highly multithreaded."

Unfortunately for Apple customers with older Macs, Intel has not made microcode fixes available for Mac models from 2010 or earlier.

Microsoft
Microsoft in its MDS threat guidance does not take a firm stand but notes, " To be fully protected, customers may also need to disable Hyper-Threading." The Windows giant has released operating system updates to mitigate Intel's design flaw in conjunction with necessary microcode updates – see the aforementioned link.

Red Hat
Red Hat includes a link to disabling Hyper-Threading in its advisory without making a recommendation one way or another. Its Hyper-Threading (SMT) security page notes, " Various microprocessor flaws have been discovered recently. Certain issues require SMT be disabled in order to more fully mitigate the issue."

The enterprise Linux slinger has more technical notes here and here on the cause and effects – or you can check out the vid below. Other Linux distros should be rolling out their fixes, too. Here's the state of play with Ubuntu and Debian, for instance.

Google Cloud only recommends disabling Hyper-Threading for Compute Engine users "if you are using Container Optimized OS (COS) as your Guest OS and you are running untrusted, multi-tenant workloads in your virtual machine." It makes a similar recommendation for those running untrusted code on multi-tenant services within Kubernetes Engine.

Xen, which makes a hypervisor used by AWS ( advisory) and other cloud providers others, has issued an advisory that details the risks of Hyper-Threading while refusing to disable the technology by default because doing so would be too disruptive. Mitigations and fixes are available from the aforementioned link.

" Leakage of data from Xen or other guests can only prevented entirely by disabling hyper-threading (if available and active in the BIOS), and by applying the patches to Xen," its advisory stated.

Qubes, which relies on Xen for virtualization, says much the same.

Intel is fine with its technology, and leaves the decision to disable Hyper-Threading to its industry partners.

"Intel is not recommending disabling HT," a company spokesperson told The Register in an email.

"It’s important to understand that disabling SMT/HT does not alone provide protection against MDS, and doing so may impact workload performance or resource utilization that can vary depending on the workload.

"After systems are updated, there are some cases where additional considerations may apply. Our software partners will provide guidance that can help customers make the right decisions for their systems and the workloads critical to their needs.""

Comments

What about AMD cpu's?
The researchers did test with AMD and ARM: "they were unable to replicate any of their attack primitives"

Buffer the Intel flayer: Chipzilla, Microsoft, Linux world, etc emit fixes for yet more data-leaking processor flaws
Intel CPUs dating back a decade are vulnerable to latest cousin of Spectre
By Thomas Claburn in San Francisco 14 May 2019 at 17:00
https://www.theregister.co.uk/2019/05/14/intel_sidechannel_vulnerability/

" The vulnerabilities appear to be limited to Intel hardware; the researchers say they were unable to replicate any of their attack primitives on Arm or AMD-designed processors."

" The attack, the researchers say, steals secret and sensitive data from across user-space processes, CPU protection rings, virtual machines, and SGX enclaves. "We demonstrated the immense attack potential by monitoring browser behaviour, extracting AES keys, establishing cross-VM covert channels or recovering SGX sealing keys," the ZombieLoad paper explains. "Finally, we conclude that disabling hyperthreading is the only possible workaround to mitigate ZombieLoad on current processors."

According to Gruss, the boffins also discovered that the line-fill buffer can be used to bypass Foreshadow mitigations, though that's not detailed in either paper.

Intel disagrees about the need to disable hyperthreading, and says it plans to add additional hardware defenses to address these vulnerabilities into future processors."

 

Intel’s New Spectre-Like Flaw Affects Chips Made Since 2008
by Lucian Armasu May 14, 2019 at 10:06 AM
https://www.tomshardware.com/news/intel-disable-hyper-threading-spectre-attack,39333.html

"Update, 5/14/19, 1:47pm PT: Added multiple items, posted underneath update note below:

Intel clarified that it's not recommending everyone to disable Hyper-Threading, but that some of its customers should consider the option [disabling hyper-threading] depending on their security needs:

" 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."

Google seems to be one of those select customers which considers the risk of keeping HT enabled just too big. The company has published on the Chromium site that HT will be disabled in Chrome OS version 74 :

"To protect users, Chrome OS 74 disables Hyper-Threading by default. For the majority of our users, whose workflows are primarily interactive, this mitigates the security risk of MDS without a noticeable loss of responsiveness. Chrome OS 75 will contain additional mitigations."

Original, 5/14/19, 10:06am PT:

Spoiler

Intel unveiled yet another speculative execution side-channel flaw in its processors. The vulnerability affects most of the company’s processor SKUs, except the 8th and 9th generation chips, which Intel said includes hardware mitigations against this flaw.

Microarchitectural Data Sampling in Intel Chips
The Microarchitectural Data Sampling (MDS) issue is a speculative execution side-channel attack that may allow malicious actors to locally execute code in order to extract sensitive data that would otherwise by protected by Intel processors’ architectural mechanisms.

According to Intel, four CVEs were assigned to this flaw in Intel’s processors, including:

• 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)

Significant Changes to Operating Systems, Core Software Are Required
Intel believes that in order to protect users against this speculative execution issue, Microsoft and other operating system vendors, hypervisor vendors, as well as Intel itself will need to implement significant changes in their software. The solution will involve clearing microarchitectural buffers when switching to software that is not trusted by the previous software.

For instance, every time a processor would switch from one third-party app to another, from a Windows process to a third-party app, or even from less trusted Windows processes to more trusted ones, the buffers would have to be cleared or overwritten. Adding such a significant step in the processing software will most likely lead to a performance loss. How large or small, it remains to be seen, but chances are it could be on the significant side.

Intel Recommends Disabling Hyper Threading
The company admitted in its white paper that the software mitigations will have a significant effect on how HT works. The threads will need a higher level of isolation between each other, and they will not be able to run processes from different security domains anymore. Threads from different security domains will simply become idle (thus turning into wasted processing power).



Image credit: Intel

It seems that with every other speculative execution attack, Intel’s Hyper Threading becomes either less secure or slower. Intel itself seems to be moving away from Hyper Threading lately on some of its best CPUs, even in the face of AMD competition with both higher number of cores and simultaneous multithreading (SMT) support at similar price points.

Intel has also been publicly reluctant to agree with the disabling of HT when others have called for it with the discovery of some previous CPU flaws, but in its paper, the company stated that disabling HT altogether may be warranted as protection against MDS attacks.

Despite all of these drawbacks, Intel did mention in the white paper that these software mitigations are highly recommended, despite the vulnerabilities being classified only low to medium severity.

Intel noted that future processors will have data sampling methods mitigated in hardware. Some of the company’s current chips could also enable similar mitigations, but only after a microcode update has been loaded. In other words, you’ll rely on your motherboard maker or laptop maker to deliver that update to you, before you can benefit from this mitigation.

Affected Processors
Virtually all of Intel’s chips starting with the Nehalem architecture (launched in 2008, 11 years ago) and newer, with the exception of the Whiskey Lake (ULT refresh), Whiskey Lake (desktop), as well as the Atom and Knights architectures, are affected by the MDS vulnerabilities.

What this tell us is not only that there are now multiple speculative execution attacks against Intel’s processors, or that there will be more to come until a Intel applies a more significant overhaul to its architecture, but that most of these chips will likely never be patched against this flaw and others like it. Motherboard and laptop OEMs tend to update only their most recent products, so the majority of systems sold in the past 11 years will likely remain vulnerable.

Those that do get the patches shouldn’t necessarily consider themselves that much luckier either, as the performance loss after the patches are applied could be significant. Those who buy the new Intel chips starting with Whiskey Lake refresh and later should see a much lower performance loss as well as the security protection from the built-in hardware mitigations, at least until a new speculative execution attack appears that can bypass the new mitigation appears.

Intel has provided more information about the MDS flaws, including about how to get the software patches, on its website.

Product Status: Microarchitectural Data Sampling (MDS)
Google’s Mitigations for Microarchitectural Data Sampling
https://support.google.com/faqs/answer/9330250

Overview
This document lists affected Google products and their current status of mitigation against the CPU side channel issues known as Microarchitectural Data Sampling (MDS), described in CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091.

The issue has been mitigated in many Google products (or wasn’t an issue in the first place). In some instances users and customers may need to take additional steps to ensure they’re using a protected version of a product, as detailed below.

This list and a product’s status may change as new developments warrant.

Google Products and Services
[Long list of services, please go to URL above to view them...]

 

Linux still clubs Kabylake and newer versions as Skylake + models so even with hardware fixes you are still vulnerable to newer variants unless you buy a better PCs, its a new ad to promote the sales of PCs not with Intel Inside.
Updated uCodes for Intel Intel/AMD uCode fix for Spectre, HT bug fix and Meltdown.

 

Cybersecurity Flaws in Chips Are Still Taking Too Long to Fix
https://medium.com/mit-technology-r...are-still-taking-too-long-to-fix-a9b037e774b7
Delays in plugging security holes in semiconductor chips put everything from servers to phones at risk. Here are some suggestions for speeding things up.

 

News Corner | Intel CPU Flaws Strike Again! AMD's New 'Navi 14' Radeon GPU

 

A New Flaw In Zoom Could Have Let Fraudsters Mimic Organisations
https://thehackernews.com/2020/07/zoom-vanity-url-vulnerability.html

zoom vulnerability
In a report shared with The Hacker News, researchers at cybersecurity firm CheckPoint today disclosed details of a minor but easy-to-exploit flaw they reported in Zoom, the highly popular and widely used video conferencing software.

 

In a first, researchers extract secret key used to encrypt Intel CPU code arstechnica.com

Hackers can now reverse-engineer updates or write their own custom firmware.


“For now, there's only one but very important consequence: independent analysis of a microcode patch that was impossible until now,” Positive Technologies researcher Mark Ermolov said. “Now, researchers can see how Intel fixes one or another bug/vulnerability. And this is great. The encryption of microcode patches is a kind of security through obscurity.”

 

I guest that means new microcode update to fix the issue with a performance impact.

Sent from my SNE-LX1 using Tapatalk

 

Newer ucode cut your performance in half literally when used in-conjunction with OS updates.

 

I am just going off the last couple of ucode updates via bios with OS microcode updates for Meltdown and spectre.

Sent from my SNE-LX1 using Tapatalk

 

Yeah I'm using CC uCode instead of D6/E2 which kills performance and max undervolt values when applied on Linux and Windows. So in Linux I undervolt to -100mV and on windows with older uCode CC -125mV. It simply gets stuck at black screen when left idle for a min.