Intel CPU processor security hole - another one (Hits LINUX and Windows) [Archive]

View Full Version : Intel CPU processor security hole - another one (Hits LINUX and Windows)

Bob

23rd November 2017, 01:00

Intel CPU processor security hole - another one (Hits LINUX and Windows)

(Note: Re-copying the TITLE of the thread to prevent any 'confusion'. If you are running on an AMD CPU or other central processing unit, don't bother trying to run the INTEL cpu testing program :Angel: )

"Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs.

"If you are at risk, you must obtain and install firmware updates from your computer's manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine."

oops...

Security
Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets
Bugs can be exploited to extract info, potentially insert rootkits

Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets...

Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts.

The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, to run code beneath the operating system to spy on or meddle with the computer completely out of sight of other users and admins. The holes can also be exploited by network administrators, or people masquerading as admins, to remotely infect machines with spyware and invisible rootkits, potentially.

Meanwhile, logged-in users, or malicious or commandeered applications, can leverage the security weaknesses to extract confidential and protected information from the computer's memory, potentially giving miscreants sensitive data – such as passwords or cryptographic keys – to kick off other attacks. This is especially bad news on servers and other shared machines.

Any program which created "elevated privileges" can gain access.. (I've talked about certain programs before which have been demonstrated to create "elevated privileges"..)

The INTEL CPU manufacturer download for the vulnerability check is located here:
https://downloadcenter.intel.com/download/27150 (Intel-SA-00086 Detection Tool) pick OS

Affected products:

6th, 7th & 8th Generation Intel® Core™ Processor Family
Intel® Xeon® Processor E3-1200 v5 & v6 Product Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon® Processor W Family
Intel® Atom® C3000 Processor Family
Apollo Lake Intel® Atom Processor E3900 series
Apollo Lake Intel® Pentium™
Celeron™ N and J series Processors

After running it check the LOG file to see if you have a potentially compromised CPU. I've run it and my CPU shows safe for this hardware bug.

reference pages:
https://www.theregister.co.uk/2017/11/20/intel_flags_firmware_flaws/
and
https://arstechnica.com/information-technology/2017/11/intel-warns-of-widespread-vulnerability-in-pc-server-device-firmware/

The company has posted a detection tool on its support website for Windows and Linux to help identify systems that are vulnerable. In the security alert, members of Intel's security team stated that "in response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of its Intel® Management Engine (ME), Intel® Trusted Execution Engine (TXE), and Intel® Server Platform Services (SPS) with the objective of enhancing firmware resilience."

Four vulnerabilities were discovered that affect Intel Management Engine firmware versions 11.0 through 11.20. Two were found in earlier versions of ME, as well as two in Server Platform Services version 4.0 firmware and two in TXE version 3.0.

Michelle Marie

23rd November 2017, 01:12

"Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs.

"If you are at risk, you must obtain and install firmware updates from your computer's manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine."

oops...

Security
Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets
Bugs can be exploited to extract info, potentially insert rootkits

Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets...

Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts.

The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, to run code beneath the operating system to spy on or meddle with the computer completely out of sight of other users and admins. The holes can also be exploited by network administrators, or people masquerading as admins, to remotely infect machines with spyware and invisible rootkits, potentially.

Meanwhile, logged-in users, or malicious or commandeered applications, can leverage the security weaknesses to extract confidential and protected information from the computer's memory, potentially giving miscreants sensitive data – such as passwords or cryptographic keys – to kick off other attacks. This is especially bad news on servers and other shared machines.

Any program which created "elevated privileges" can gain access.. (I've talked about certain programs before which have been demonstrated to create "elevated privileges"..)

The INTEL CPU manufacturer download for the vulnerability check is located here:
https://downloadcenter.intel.com/download/27150 (Intel-SA-00086 Detection Tool) pick OS

Affected products:

6th, 7th & 8th Generation Intel® Core™ Processor Family
Intel® Xeon® Processor E3-1200 v5 & v6 Product Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon® Processor W Family
Intel® Atom® C3000 Processor Family
Apollo Lake Intel® Atom Processor E3900 series
Apollo Lake Intel® Pentium™
Celeron™ N and J series Processors

After running it check the LOG file to see if you have a potentially compromised CPU. I've run it and my CPU shows safe for this hardware bug.

reference pages:
https://www.theregister.co.uk/2017/11/20/intel_flags_firmware_flaws/
and
https://arstechnica.com/information-technology/2017/11/intel-warns-of-widespread-vulnerability-in-pc-server-device-firmware/

The company has posted a detection tool on its support website for Windows and Linux to help identify systems that are vulnerable. In the security alert, members of Intel's security team stated that "in response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of its Intel® Management Engine (ME), Intel® Trusted Execution Engine (TXE), and Intel® Server Platform Services (SPS) with the objective of enhancing firmware resilience."

Four vulnerabilities were discovered that affect Intel Management Engine firmware versions 11.0 through 11.20. Two were found in earlier versions of ME, as well as two in Server Platform Services version 4.0 firmware and two in TXE version 3.0.

Just desktops? 💁 Not laptops?

Thanks,
MM

Bob

23rd November 2017, 01:16

mojo

23rd November 2017, 02:34

6th, 7th & 8th Generation Intel® Core™ Processor Family

Does 7 generation mean I7? Not sure but Im running a newer I7...

DeDukshyn

23rd November 2017, 03:26

I recently refreshed my system with one of the new AMD 8 core Ryzen processors. I paid far less than half of what a i7-6900k costs but get 98% of the full load performance and better single core performance (with an overclock). :)

being a new platform though, it doesn't come without it's own risks ...

ThePythonicCow

23rd November 2017, 03:27

6th, 7th & 8th Generation Intel® Core™ Processor Family

Does 7 generation mean I7? Not sure but Im running a newer I7...

The 6th Generation "Skylake" Intel Core Desktop SKU's include such CPU's as the Core i7-6700, Core i5-6400, and Core i3-6100. Intel introduced this Generation in the second half of 2015.

The 7th Generation "Kaby Lake" includes desktop SKU's Core i7-7700, Core i5-7400, and Core i3-7100. Intel introduced this Generation in the second half of 2016.

The 8th Generation "Coffee Lake" includes desktop SKU's Core i8-8700, Core i5-8400 and Core i3-8100. Intel introduced this Generation in the second half of 2017.

Each Intel "Core" generation includes various mobile and Xeon SKU's, in addition to such desktop SKU's as listed above.

As I noted with bold font above, the "Generation" number is shown in the first digit of the four digit model number.

In each Generation, the i7's are the higher end desktop and mobile SKU's, the i5's are the mid-range SKU's, and the i3's are the lower end SKU's.

DeDukshyn

23rd November 2017, 03:29

6th, 7th & 8th Generation Intel® Core™ Processor Family

Does 7 generation mean I7? Not sure but Im running a newer I7...

7th and 8th gen are fairly recent - you could susceptible to this bug.

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

It seems it potentially covers a broad range of all reasonably recent Intel processors - this would include laptop processors as well.

ThePythonicCow

23rd November 2017, 03:33

Bob

23rd November 2017, 05:22

Hard telling - its based on the CPU type. The detection tool seems to work. I've run it on my laptop(s) for the I7 and it's clear.. I have numerous desktops to try the detection app on tho.. both Linux and windows..

detection app page: https://downloadcenter.intel.com/download/27150

Hah - that Intel tool informs me that my "AMD Ryzen 7 1700 Eight-Core Processor" may be vulnerable :).

Wonder why u were running an INTEL CPU checking app on an AMD Ryzen ;)

btw, with u running Linux, https://www.extremetech.com/computing/254750-amd-replaces-ryzen-cpus-users-affected-rare-linux-bug

AMD Replaces Ryzen CPUs for Users Affected By Rare Linux Bug

ref: https://www.extremetech.com/computing/254750-amd-replaces-ryzen-cpus-users-affected-rare-linux-bug

there’s been one low-level problem that we’ve been watching but haven’t previously reported on. In early June, Ryzen users running Linux began reporting segmentation faults when running multiple concurrent compilation workloads using multiple different versions of GCC. LVVM/Clang was not affected, and the issue appears confined to Linux. Moreover, it wasn’t apparently common, even among Linux users — Michael Larabel, of Phoronix.com, reported that his own test rigs had been absolutely solid, even under heavy workloads.

Like the Pentium FDIV bug of yesteryear, this was a real issue, but one that realistically only impacted a fraction of a fraction of buyers. AMD had previously said it was investigating the problem (which isn’t present on any Epyc or Threadripper CPUs) and it’s now announced a solution: CPU replacement.

Phoronix reports AMD provided them with a new Ryzen 7 1800X CPU and that this chip has refused to crash, even when running a “kill Ryzen” script that would previously deliberately create a compiler segmentation fault. While some users thought the issue was confined to a RAM, motherboard, or BIOS-related issue, Phoronix’s testing proves otherwise. Swap the new Ryzen 7 1800X for an older part, and the problem reappears. Switch back to the new chip, and it vanishes. Larabel has tentatively concluded that the issue appears confined to Ryzen CPUs manufactured before Week 25 of this year (the new chip was built in Week 30), but no other details on what caused it are available.

The good news is, AMD is replacing the CPUs of anyone who has this issue. Again, while the issue is real, it appears to only trigger in an extremely small number of cases when running a Linux workload under specific and particular circumstances.

CPU Errata Are the Rule, Not the Exception
We tend to think of CPU errata as being show-stopping phenomena that occur only occasionally, but the opposite is true. The summary table of errata within Intel’s sixth-generation Core family is eight pages long. Most of these bugs are minor issues or relate to corner cases, but larger issues can break through. Intel’s original Atom architecture had a major FPU bug in which trying to perform two back-to-back x87 operations would double the execution time. CPU analyst Agner Fog writes (Page 162 / 233):

Whenever there are two consecutive x87 instructions, the two instructions fail to pair and instead cause an extra delay of one clock cycle due to problems in the decoders. This gives a throughput of only one instruction every two clock cycles, while a similar code using XMM registers would have a maximum throughput of two instructions per clock cycle.

This applies to all x87 instructions (names beginning with F), even the FNOP. For example, a sequence of 100 consecutive FNOP instructions takes 200 clock cycles to execute in my tests. If the 100 FNOPs are interspersed by 100 NOPs then the sequence takes only 100 clock cycles. It is therefore important to avoid consecutive x87 instructions.

I thought about getting a Ryzen at one point but rejected that though -

this is one of the reasons - AMD’s latest Ryzen processors performance hit by Windows 10 Scheduler bug

Unfortunately it seems Windows users on the latest version of Microsoft’s desktop OS will not be able to get the maximum benefit from the high performance, good value solution.

A bug has been discovered in the Windows 10 Scheduler which limits the performance of AMD Ryzen CPUs. The issue is due to the difference between how Windows treat threading between Intel and AMD processors.

For Intel hyperthreading it appropriately prioritizes the main thread and gives secondary threads lower priority. With AMD processors it treats all the threads as equal, meaning lower priority tasks are treated the same as higher priority tasks and overall performance suffers.

Another bug also incorrectly identifies the amount of cache available per thread, with the Windows 10 Scheduler thinking each thread has 136 MB of RAM rather than the actual 20 MB available in the L2+L3 cache combined.

At present the issue is only believed to affect Windows 10. Windows has had scheduler issues in the past, so we are sure a solution is only a software update away.

In the mean time users can disable SMT in the BIOS to improve performance in gaming, but for more multi-threaded work it may be better to leave it enabled.

ref: https://mspoweruser.com/amds-latest-ryzen-processors-performance-hit-by-windows-10-sheduler-bug/

due to the programs I have, they are not ported into Linux, so I am stuck with Windoz.. :P

Ryzen's - https://community.amd.com/thread/219589

I have found that my Ryzen 7 1700 has a stable OC at 3.9 GHz using 1.4V of Vcore and has been tested by 15 min of Realbench, 1 hour linpak OCCT and Prime 95 and also serial passages of Cinebench R15 (between 5-6). My temps don't go over 58 C so still I have plenty of room to OC. However the problem comes from the chip itself that when I set my PC to sleep or shutdown for sometime on reboot the multiplier gets stuck in 15.5 bringing my CPU to 1.550 GHz completely destroying its performance. I have partially solved the problem by creating an overclocked profile with different settings (e.g. 3.975 and 1.45 Vcore), saving it into the Asus Overclocking Profile tool, loading it, press F10 to save changes and reboot to get back into the BIOS, load my desired profile back and finally into OS to unlock the multiplier back to 39. It works but is kind of annoying to have to do this everytime I reboot.

Actually, this problem seem to be happening whenever I apply offset values that place the Vcore between 1.39-1.44V for some reason. A pitty because I can see that my processor has still room to improve but is being gimped by no apparent reason.

and so forth.. stuck with Intel for now.. stuck as I am, my next rig is an I9 - I can't spend 18 hours doing a rendering to have the processor crash do to the oooops.

http://bgr.com/2017/05/29/intel-core-i9-specs-leak-vs-amd-ryzen/

I'm looking at this one (I do 3D rendering extensively) - https://www.intel.com/content/www/us/en/products/processors/core/x-series/i9-7980xe.html

Ryzens have their own issues too - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085

https://linux.slashdot.org/story/17/08/07/2056245/amd-confirms-linux-performance-marginality-problem-on-ryzen

https://www.digitaltrends.com/computing/ryzen-amd-bios-fix-fma3-crash/ - AMD found the root problem causing its new Ryzen processors to freeze desktops

DeDukshyn

23rd November 2017, 06:16

I thought about getting a Ryzen at one point but rejected that though -

this is one of the reasons - AMD’s latest Ryzen processors performance hit by Windows 10 Scheduler bug

Unfortunately it seems Windows users on the latest version of Microsoft’s desktop OS will not be able to get the maximum benefit from the high performance, good value solution.

A bug has been discovered in the Windows 10 Scheduler which limits the performance of AMD Ryzen CPUs. The issue is due to the difference between how Windows treat threading between Intel and AMD processors.

For Intel hyperthreading it appropriately prioritizes the main thread and gives secondary threads lower priority. With AMD processors it treats all the threads as equal, meaning lower priority tasks are treated the same as higher priority tasks and overall performance suffers.

Another bug also incorrectly identifies the amount of cache available per thread, with the Windows 10 Scheduler thinking each thread has 136 MB of RAM rather than the actual 20 MB available in the L2+L3 cache combined.

At present the issue is only believed to affect Windows 10. Windows has had scheduler issues in the past, so we are sure a solution is only a software update away.

In the mean time users can disable SMT in the BIOS to improve performance in gaming, but for more multi-threaded work it may be better to leave it enabled.

ref: https://mspoweruser.com/amds-latest-ryzen-processors-performance-hit-by-windows-10-sheduler-bug/

due to the programs I have, they are not ported into Linux, so I am stuck with Windoz.. :P

Ryzen's - https://community.amd.com/thread/219589

[QUOTE]I have found that my Ryzen 7 1700 has a stable OC at 3.9 GHz using 1.4V of Vcore and has been tested by 15 min of Realbench, 1 hour linpak OCCT and Prime 95 and also serial passages of Cinebench R15 (between 5-6). My temps don't go over 58 C so still I have plenty of room to OC. However the problem comes from the chip itself that when I set my PC to sleep or shutdown for sometime on reboot the multiplier gets stuck in 15.5 bringing my CPU to 1.550 GHz completely destroying its performance. I have partially solved the problem by creating an overclocked profile with different settings (e.g. 3.975 and 1.45 Vcore), saving it into the Asus Overclocking Profile tool, loading it, press F10 to save changes and reboot to get back into the BIOS, load my desired profile back and finally into OS to unlock the multiplier back to 39. It works but is kind of annoying to have to do this everytime I reboot.

Actually, this problem seem to be happening whenever I apply offset values that place the Vcore between 1.39-1.44V for some reason. A pitty because I can see that my processor has still room to improve but is being gimped by no apparent reason.

and so forth.. stuck with Intel for now.. stuck as I am, my next rig is an I9 - I can't spend 18 hours doing a rendering to have the processor crash do to the oooops.

http://bgr.com/2017/05/29/intel-core-i9-specs-leak-vs-amd-ryzen/

I'm looking at this one (I do 3D rendering extensively) - https://www.intel.com/content/www/us/en/products/processors/core/x-series/i9-7980xe.html

Ryzens have their own issues too - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085

https://linux.slashdot.org/story/17/08/07/2056245/amd-confirms-linux-performance-marginality-problem-on-ryzen

https://www.digitaltrends.com/computing/ryzen-amd-bios-fix-fma3-crash/ - AMD found the root problem causing its new Ryzen processors to freeze desktops

The windows scheduler bug was fixed immediately if it even existed as suspected, the Linux bug was patched, and the other guy's issue seems specific to him or to his mother board. I have my 1700 @ 3.85 and 1.4v, ram@3200 with 14,15,15,16,36 timings and experience no issues. The OC is rock solid (I 3D render as well and have to prove perfect stability for both RAM and CPU - 15 minutes of prime95 doesn't cut it ... 30 minutes of Arnold or Corona render with Prime95 running and CPU-z stress test simultaneously makes me feel ok though) , and it renders 1715 in Cinebench (with the OC - exceeding 6900k score by a fair margin) but only cost me three hundred and seventy on sale (Canada - MemoryExpress). :)

There were many bios updates and patches fairly soon after release that fixed most issues. I'd consider it quite a stable platform now with updates.

The 7980X is a great chip for rendering ... if you can afford it and if you can keep it cool. Threadripper 1950x gets you ~80% of the rendering power at half the price -- if price / performance ratio is a concern. :) But if you just need the processor and not extensive PCI lanes then the i9 is a good choice. Also a new platform though with it's own teething issues, but Intel is usually quick to jump on those.

I also ran the Intel checker for this bug as Paul did, but mine never completed the check after 10 minutes so I killed it. I have the same processor as his.

Bob

23rd November 2017, 06:58

Still wonder why one would want to run an Intel CPU checker program designed for the Intel chip to try to run on an AMD processor..

Every AMD I've used has given me problems, not over-clocked, running a very good power supply, good ram and a great motherboard (which was rated for overclocking). Every AMD under stress has locked up while running assorted versions of windows. As the programs I have won't port over to Linux, and it's useless to try to run emulation (due to speed and compatibility issues still with the programs, and drivers), I am stuck with windows. My programs run with multi-core, multi-thread, and such quite well. It's not a cluster although I have considered that for rendering, but, I am forced with a cluster to try to run on Linux. Again, more effort than it's worth to find a workaround.

As I said, the thread is about the INTEL built in "hidden" processor "bugs" (the ME "Management Engine" and the "Trusted :) execution Engine or TXE) which can be apparently accessed with the right tools, unbeknownst to virus checkers/spyware and so forth to perform nefarious acts.. and the bugs that have been found, long term bugs, and programs which have the ability to elevate their status above normal user-level, (and access those engines..) .. which to me is worrisome.

I don't have the series of INTEL processors which that bug is affecting. I'd wonder if such a bug was accidental or deliberate. I do need extreme rendering speed, and cutting down an 18 hour runtime to me is important, without risking a CPU lockup. I don't follow AMD's patches nor do I look at the driver sites for the AMD series of MOBO's. I would not have anything but a passing interest to see how AMD processors these days are faring. So if the AMD bugs have been fixed that is GREAT news, is it not for any AMD users.

I am running my lappies and desktops with Intel CPUs these days and intend to stick with it and it's supporting mobo's and chipsets, and go for the I9 xe on my next rig. I can't risk nor afford a waste of time for a CPU lockup crash. Intel CPU's have had its SkyLake processors mysteriously lockup as well.

Who has the best track record? Certainly the 'processor wars' will get a lot of traction in discussion, "my benchmark is better than yours, etc.."

AMD sure costs less that's for sure, but for me lockups cost me time and failed renderings and a lot of frustration.

Intel for me has been more reliable. If I could do clusters with windows and Intel CPU's I'd do that as my software (sigh) is tied at the hip to windows. No doubt with the CPU security holes, my new rig will never touch a live 'outside' network, probably a good practice.