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

The "90" is CACHE_HIT_THRESHOLD used in the predictive memory fetch algorithm. As comments note in the below posted link, a number of tests are required for the program to achieve a success result and CACHE_HIT_THRESHOLD value is CPU dependent. All showing the difficulty in pulling off a successful Spectre - variant 2 attack.

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

-EDIT- And again .........., all these tests are good for is determining if you CPU is vulnerable to Spectre - variant 2. They are useless in determining if your still vulnerable after all OS and app patches have been applied.

 

Probably CPU load is also a factor.
On the other hand if attacker wants to read 2048 bit private key and only successfully reads i.e. 1800 bit, rest 248 bits can be tried to be brute-forced.

 

I have execute the script locally.
I used the parameter "remotesigned".
Remember to restore the policy to default:

 

I finally got all my bottom up ASLR high entropy issues in WDEG resolved. However, I discovered another MS "goodie" in the process.

I am posting this here since I started the discussion here, rather than in the last fall Wilders thread on the issue of Mandatory ASLR and the creation of the MitigationOptions reg. key with setting on both Mandatory and Bottom-up ASLR at the system level. I am sure I am not the only one affected by this. Note: this posting only applies to x64 OS users.

The reference MS article to the original issue is here: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ . Scroll down to this paragraph:

Next, note in the picture for app level Bottom-up ASLR shown in the article that the setting for "Don't use high entropy" is enabled. Well as it turns out MS in the "convoluted" logic they use in regards to WDEG behavior, changes default "opt-out" behavior for mitigations options to "opt-in" behavior when overridden at the system level. Bottom-up ASLR is one of those mitigations. Clarifying when Bottom-up ASLR is set on at the system level, the app level Bottom-up ASLR option for high entropy is an "opt-in" one and must be enabled.

Next, open up WDEG app settings and select for example, those shown for iexplore.exe. Note that the default setting for "Bottom-up ASLR - Don't use high entropy" is unchecked. Translation - high entropy is not being deployed. Ditto for any other app listed that is overriding system level Bottom-up ASLR. For any of those that are 64 bit processes, the "Don't use high entropy" setting must be manually enabled.

All the above can be verified by using Process Explorer, right clicking on a selected process, and selecting "Properties." Scroll down to "Address Space Load Randomization" and it will show "High-Entropy" if it is being deployed.

If all this gives you a "brain cramp" reading, join the club.

 

Can you insert 2 images (On - Off)?

 

Assuming you have set on Bottom-up ASLR at system level, verify your current setting for ASLR using Process Explorer as I described previously. If they correspond with what I posted, then:

-EDIT- This example only applies if you're using 64 bit Firefox.

1. Bottom-up ASLR - high entropy is disabled



2. Bottom-up ASLR - high entropy is enabled



Now re-verify firefox.exe ASLR setting shows"High-entropy" using Process Explorer.

 

On my System is default setting.

 

If you never overrode Bottom-up ASLR at system level, i.e. MitigationOptions reg. key value for same set to "1", then none of what I posted is applicable.

 

Another "glitch" I have found in regards to Bottom-up ASLR - high entropy is that it is not enabled for x64 explorer.exe. It appears to be the only Win OS process like this. Considering how often it is targeted by attackers, I consider this a security vulnerability.

 

I have been following this thread, and I have received the Microsoft mitigation updates from earlier this month, and now I have run GRC's InSpectre for the first time, and it shows that I am protected for Meltdown. As to Spectre, I am not too concerned.



"This 64-bit OS on Intel Processor:
OS is Meltdown aware: Yes
OS is Spectre aware: No
OS Meltdown data: 0x000D
OS Spectre data: n/a
PCID/INVPCID support: Yes / Yes
CPU microcode updated: Yes
CPU is meltdown vulnerable: Yes
This system's processor identification:
Intel Core i5-6300U CPU @ 2.40GHz
Documentation of Meltdown (KVA) and Spectre (branch control speculation) bit flags returned by the NtQuerySystemInformation call which, when supported by updated versions of Windows as shown above, provides detailed information about Windows' management of these vulnerabilities:
KVA (Meltdown Vulnerability) flags:
==================================
0x01 KVA_SHADOW_ENABLED
0x02 KVA_SHADOW_USER_GLOBAL
0x04 KVA_SHADOW_PCID
0x08 KVA_SHADOW_INVPCID
Branch Prediction Speculation (Spectre) flags:
==================================
0x01 BPB_ENABLED
0x02 BPB_DISABLED_SYSTEM_POLICY
0x04 BPB_DISABLED_NO_HW_SUPPORT
0x08 SPEC_CTRL_ENUMERATED
0x10 PRED_CMD_ENUMERATED
0x20 IBRS_PRESENT
0x40 STIBP_PRESENT
0x80 SMEP_PRESENT

The presence of the relatively recent PCID and INVPCID support allows Windows (when it chooses to take advantage of this) to protect against the Meltdown vulnerability without significant system performance impact.

AMD processors do not require, do not offer, and do not need the PCID and INVPCID support since they are inherently invulnerable to Meltdown attack.

"CPU microcode updated" indicates that this system is using recently updated Intel or AMD microcode which provides the control over branch prediction speculation required to allow an aware operating system to protect the system from the Spectre vulnerabilities.

This application will run under WINE and can therefore be used on non-Windows systems. Although its operating system data may not be meaningful under WINE, its display of the underlying processor capabilities will be accurate.

For more information see GRC's InSpectre web page
Copyright © 2018 by Gibson Research Corporation"

Edit: Emphasis added with blue color, by me.

 

"Intel reportedly notified Chinese companies of chip security flaw before the U.S. government..."

https://techcrunch.com/2018/01/28/i...rity-flaw-before-the-u-s-government/?ncid=rss

"...The decision raises concerns, security researchers said, as it potentially could have allowed information about the chip flaws, dubbed Spectre and Meltdown, to fall into the hands of the Chinese government before being publicly divulged..."

https://www.marketwatch.com/story/i...flaws-before-warning-us-government-2018-01-28

 

Windows Update KB4078130 deactivates Spectre Patch
January 29, 2018
https://www.ghacks.net/2018/01/29/windows-update-kb4078130-deactivates-spectre-patch/

Code:

To disable Spectre Variant 2:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 1 /f
To enable Spectre Variant 2:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 1 /f

 

Why Intel CPUs are vulnerable to Sprectre;

Why AMD CPU's are much less vulnerable to Sprectre and minimally if at all affected performance wise by OS Spectre patches:

Why Intel CPU performance will still be affected after BIOS Spectre patches applied:

https://www.reddit.com/r/Amd/commen...tion_and_speculative/?st=jd0bi9ux&sh=2a837b4f

-EDIT- I was also reading on a few authoritive web sites last night that Intel was long ago aware of their methods of speculative execution and branch prediction could theoretically be exploited but they were unable to do so in their lab testing. Therefore they assumed the method was safe.

 

I'm curious why you don't think this is an issue in Process Explorer itself, instead of Windows Defender.

 

HP Support Assistant just prompted me for a firmware update.

After:



I guess this is what we want to see?

 

Yes it is I've got not BIOS updates for any of my HP laptops yet.

 

My BIOS was F.34 updated recently thanks to @anon and is F.34 still now.

I didn't run InSpectre after I updated the BIOS on the 21nd of January because it was still older (18th of December I think) but I wouldn't think I would be prompted to install the same BIOS version.

 

8(>_<)8

I'm so jealous. I doubt my second-gen core i7-based ASUS laptop will ever have those results.

 

@Krusty Are you getting any kind of hardware errors in Event Viewer?

 

No, it is not an issue w/Process Explorer. Before I get into that I need to discuss a couple of other points.

First in regards to the enabling of system-wide forced randomization and bottom-up ASLR mitigation discussed here: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ , Microsoft was 100% correct in stating it should not be deployed other than in environments where security policy mandates mandatory ASLR be deployed. On my old motherboard, this was the reason my audio driver and other M/B chipset associated drivers have been periodically acting up. These are expecting drivers to be located in fixed locations. I have since disabled the mitigations. Also additional testing yielded these mitigations have no impact on 64 bit process high entropy.

I also did additional research on 64 bit process high entropy which yield the following:

1. It is set on by default for all 64 bit processes:

https://docs.microsoft.com/en-us/cpp/build/reference/highentropyva-support-64-bit-aslr

2. Additionally, 64 bit DLLs must opt-in to it:

http://www.itprotoday.com/windows-8/windows-8s-new-security-features

Now to the WDEG app level high entropy issue I previously posted about.

As far as the forced randomization and bottom-up ASLR mitigations enabled at the app level, those are only applicable to the 32 bit versions on the processes where they are enabled. As noted above, these mitigations are set on by default for 64 bit processes.

Using IE11 as one example what I observed though testing is that if the "Don't use high entropy" option setting for bottom up ASLR is disabled, it appears that ieplore.exe and all .dlls loaded at process start-up time employed high entropy as evidenced by their load memory addresses all > 0x7FF.......... However, Process Explorer still shows that high-entropy ASLR is not enabled for IE11. I do not believe this is a bug in PE since it correctly shows the high-entropy ASLR status for all processes except those specifically defined at the app level in WDEG. That is except for explorer.exe which I believe is some weird anomaly that needs further analysis. I therefore conclude that there is a bug in WDEG at the app setting level that is setting off the above noted HIGHENTROPYVA and/or DYNAMICBASE parameters after the process loads. Since I don't know what the impact of this is, I am sticking to my original recommendation to enable the "Don't use high entropy" option setting for bottom up ASLR at the app level for any 64 bit process defined there.

 

https://www.extremetech.com/computi...y-lost-market-share-amd-2017?source=Computing

 

My other older machines won't be patched either.

I'll check it out. What should I be looking for and where?

 

@itman. Tnx. That clarifies quite a bit.

Intel’s 9th-generation ‘Ice Lake’ CPUs will have fixes for Meltdown, Spectre
“Ice Lake” family of processors is expected to launch by the end of 2018 or in early 2019.

https://www.digitaltrends.com/computing/intel-meltdown-spectre-silicon-fixes-ice-lake/

 

Under Windows Logs > Applications and Services Logs > Hardware Events show as "0". Is that where I should be looking, or elsewhere?

 

;

Mine were showing under Custom Views - Administrative Events and under System

Here is an example from mine which occurred 2x per minute:

Code:

Log Name:      System
Source:        Microsoft-Windows-WHEA-Logger
Date:          2018-01-12 4:43:12 PM
Event ID:      19
Task Category: None
Level:         Warning

Description:
A corrected hardware error has occurred.

Reported by component: Processor Core
Error Source: Corrected Machine Check
Error Type: Internal parity error
Processor APIC ID: 0

My hope is that your system is running fine and without these errors.