'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

I was already livid with Intel's behaviour of merciless profit squeezing combined with glacial improvement and minimal attention to security (both desktop and laptop), and after this, it will require a huge level of contrition and rectification (including disabling ME and all that other nonsense), before I'll send money their way - at least AMD are showing competitive performance.

I'd echo the comments above, +1

"I might buy one with AMD inside ..."

PS - I'm under no illusions about AMD either, but for sure, it does us no good whatsoever to have such an extended market dominance as Intel has had.

 

Thanks for confirming WBD.

And thanks again for your research here, and 'rescuing' my ThinkPad, for now . Much appreciated.

 

Since you brought it up, do you think that CPU speeds could have progressed much faster ? Adding extra cores will only do so much.

 

No, I don't think clock speeds can increase much without consuming too much power. But in practice, a multitasking system which is in any way well-written does benefit from extra cores and encryption-on-chip. High level language support and a bit of coding effort for multithreading can work wonders too. Most of the zip in a system is from the graphics cards and ssd these days. I also think there can be safe CPU optimisation in future IF designed properly - so that the exploit isn't possible or would take way too long - maybe a bit more silicon and skilled effort. Intel's cash pile can pay for that. I also want more cores because of my VM habit, which I think is essential for security and privacy these days - in a big way attempting to mitigate the horrific weakness of client systems. It's a huge annoyance that this debacle is threatening guest isolation too.

I don't think I'm alone in my exasperation with Intel, Linus is scathing for sure.

As a practical illustration of multicore, I have a dual Xeon rig with oodles of memory, and although that's a reasonably old part without all the optimisations of the latest i7s, it performs wonderfully, and smoothly, and supports many VMs.

My main gripe is that Intel starved the desktop market of more than 4 cores, economically, and laptop one of 2 cores. In the case of consumer laptops, had the 8G ram limit too. Some systems not supporting VT-x and VT-d. Nothing to do with cost, everything to do with profit. No wonder the desktop/laptop market has been moribund for many years.

 

HP pulled the updates as well:

https://support.hp.com/us-en/document/c05869091

 

source (bleepingcomputer.com): https://www.bleepingcomputer.com/ne...ustomers-to-not-install-spectre-bios-updates/

 

* Updated 1/24/2017 to correct previous discrepencies *

To clarify the FeatureSettingsOverride registry key use, I am posting this.

First, the CVE's for Meltdown and Spectre:

• CVE-2017-5715 (branch target injection) - Spectre variant 2
• CVE-2017-5753 (bounds check bypass) - Spectre variant 1
• CVE-2017-5754 (rogue data cache load) - Meltdown
​

Next from the Microsoft article on the subject:

https://support.microsoft.com/en-us...-to-protect-against-the-speculative-execution

Interpreting the above yields:

All mitigations enabled - binary 00 or hex* 0
Spectre - variant 2 disable - binary 01 or hex* 1
Meltdown disabled - binary 10 or hex* 2
Both mitigations disabled - binary 11 or hex* 3

* FeatureSettingsOverride is a Dword value shown in the registry as 0x00000000.
​

Since Microsoft doesn't reference CVE-2017-5753 - Spectre variant 1, it appears this can only be mitigated by app software updating. Therefore, there appears to be a direct correlation between a BIOS update and the WIN OS patch issued for CVE-2017-5715.

-EDIT- It appears the Intel BIOS updates are only addressing, CVE-2017-5715 (branch target injection), Spectre variant 2 as evidenced by the recent BIOS update Dell just pulled:

From the Dell advisory itself:

https://www.bleepingcomputer.com/ne...ustomers-to-not-install-spectre-bios-updates/

In any case, this again shows that the OS mitigation for Spectre - variant 2 needs to remain enabled until the BIOS update has been applied successfully. Successful means the BIOS update is not creating operational issues and has been proven to be as an effective mitigation as the OS patch. Until this occurs, I would leave the OS patch in place.

 

Thanks for clarifying.

 

Hi to all.
For me the only test able to really verify the vulnerability of the CPU is the Poc of Erik August:

https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

In the comments we note that some CPUs not vulnerables in the Intel List are instead exposed:

P.S. Core 2 Duo has FSB !!

 

You're welcome, my pleasure. Hopefully Intel sorts this messy microcode situation up as soon as possible so that we don't have to resort to tricks like this for too long.

 

Exactly. Plus the testing effort required in the form of repetitive algorithm changes with only limited success as noted in the comment posted show just how difficult it is to pull off a Spectre - variant 2 exploit.

I am beginning to believe that the published research POCs are amounting to a "mad dog chasing his tail" exercise.

 

It'd be great to know what user-space programs actually required very accurate rdtsc. I bet extremely few of them legitimately need that much accuracy in reported time. Hopefully this will be an obvious possible solution, namely a switch to ensure that high-resolution timing is restricted to ring 0. Maybe that'll need a new processor version though.

It's also a benefit to interpreted languages, that timing jitter/granularity protections can be put in the interpreter as per FF Jit without any other changes.

 

I tried to run a test with the only exe I found:

https://github.com/gentilkiwi/spectre_meltdown/blob/master/ErikAugust_724d4a969fb2c6ae1bbd7b2a9e3d4bb6/spectre.exe

in my PC W.10 x64 not work.

We need to disable real time protection in WD that recognizes it as an exploit:



No intervention by OSArmor.

 

Eset also blocks the download as Generik.GQSYVD Trojan. This indicates they have a generic DNA signature in place that can detect the code patterns used to monitor memory timing activities used by the .exe.

As far as OSArmor and other anti-exploits detecting the activity it performs, they really are not "geared" to detecting memory read access activities.

Which indicates the OS patch is doing its job properly. You would have to disable the Spectre OS patch and then run the .exe to determine if your CPU is vulnerable. And that itself might not prove anything since the "timings" might have to be "tweaked" in the source code and it recompiled.

 

Here's something else to ponder.

Just exactly are the BIOS updates doing? For me, the documented system lockups, blue screens, and the like are revealing. The BIOS contains all your hardware interface settings. Things like memory speed and timings, CPU voltage settings plus FSB/memory controller speeds, timings, and the like. Its quite obvious that Intel is "fooling around" with these settings which affect CPU cache accessing speeds and the like.

The first thing that popped into my mind when these exploits surfaced was the impact of overclocking as a possible mitigation to these attacks. It is reasonable to assume that any attacker is going to "tailor" his attack to stock CPU operating parameters.

Additional factors in this area are the impact of built-in CPU power management routines that dynamically change processor speeds and voltage requirements. Ditto for graphics processors that do the same.

 

With XP you get the message:

"Spectre.exe is not a valid win 32 application"

We must recompile.

 

I don't think it is that easy: https://www.wilderssecurity.com/posts/2730879/

 

Tried running Spectre.exe with Administrator privileges.
It is not signed.
I had to change my Registry protection "Validate Admin Code Signatures".
Nothing to do.




P.S. I have not disabled the patch.

 

Thanks. I'd imagine you could wrap some of these calls so that it could trap if too many done in too short a period though, that sort of thing.

The exploitation of GPU timers with WebGL is fiendish though - gah!

 

You will have to find out why the program is hanging/terminating. I would start with Win 10 WD Security Center and check under reliability history for today. Expand details for spectre.exe and it will show the error code. You can search the web on that for a detailed description. Also check your Windows event logs. I would start with Security - Mitigations and see if WDEG might be involved; that would be a nice thing to know.

-EDIT- Also since you are running OSArmor and it appears spectre.exe is opening a command prompt window, perhaps OSArmor is aborting its execution.

 

"House Energy and Commerce demands answers on Spectre and Meltdown cyber flaws

House Energy and Commerce Committee leaders are demanding answers from major technology companies affected by the Spectre and Meltdown cybersecurity flaws that leave computer chips vulnerable to hackers.

In a letter, lawmakers pressed the CEOs of Intel, Apple, Microsoft, Amazon, Google, AMD and ARM to explain the need for an "information embargo" agreement between the companies to keep information on the cybersecurity vulnerabilities from the public.

'While we acknowledge that critical vulnerabilities such as these create challenging trade-offs between disclosure and secrecy, as premature disclosure may give malicious actors time to exploit the vulnerabilities before mitigations are developed and deployed, we believe that this situation has shown the need for additional scrutiny regarding multi-party coordinated vulnerability disclosures,' the letter reads..."

http://thehill.com/policy/technolog...demands-answers-on-spectre-and-meltdown-cyber

"...The letters raise questions about why the companies agreed to delay disclosure, and seek to find out whether the involved companies considered how the delay might hurt other companies who were not kept in the loop.

Additionally, the letters bring up the matter of when the U.S. Computer Emergency Readiness Team was informed..."

https://www.cnbc.com/2018/01/24/con...l-others-about-spectre-disclosure-delays.html

 

Intel Microcode Revision Guidance
January 24, 2018
Link: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf (pdf)

 

These microcode patch attempts are turning into a circus sideshow.

 

The number of samples is growing:

https://twitter.com/avtestorg/status/955823351141949440

 

Thanks, interesting developments, interesting times. Note that this is predictably US-centric, which is problematical of itself. When would you deign to inform other countries' cybersecurity organisations, or do they assume that they already know?

I would also like them to ask the question: did our attack-oriented TLAs already know about this vulnerability and how long for? Was it assessed by the VEP?