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

I don't if anyone has looked at their Win 10 WDEG MitigationOptions registry key lately, but mine has changed. As I somewhat expected bottom-up ASLR high entropy is now enabled system-wide and has a value of "2" shown. I figured this was MS's mitigation to Spectre to force 64 bit processes to randomize memory over the wider 64 bit memory range.

Anyone have any idea of what "2" means? That value is not shown in @WildByDesign matrix.

 

? You posted you set it to "true":

-EDIT- Are you stating that the second screen shot is using that latest FireFox ver.?

 

In MitigationOptions, '2' refers to "Always Off". Essentially forcing a mitigation to be disabled at all times. So you can purposefully and forcefully disable a specific mitigation in a situation where an app developer may have enabled in within the application.

'0' is "Defer" which is Default in many cases. '0' means to Defer to what is default based on the software application's built-in choices. Essentially what the application developers have specifically opted in, or opted out of.

'1' is "Always On" and therefore forces the mitigation to be on at all times.

 

Yes.

 

Well, setting it to "2" makes no sense to me. I know I did not manually change that reg. key value.

 

Then it appears that Mozilla built-in Spectre mitigations work regardless of what privacy.firstparty.isolate is set to.

 

I agree, that is rather suspicious. You are right in that it does not make much sense and that you would not have done that manually.

This is actually interesting because I recall seeing something like that recently, back when that was brought up by CERT or somewhere around that time. I think that is a bug within WDEG that causes that. If you can reproduce the bug, let me know because I am curious about it since I did witness that happen on one of my systems recently too. I will try to reproduce later on tonight as well.

I can't remember if it was the built-in PowerShell ProcessMitigations module that caused the bug or WDEG, or more likely a bug between the two of them. I'll have to test later but this is certainly a bug and not a good thing for system security.

 

Another thing that doesn't make any sense is at the WDEG program level setings, you can only disable ASLR high entropy. This implies it is set "on" at the system level. Or, controlled by the OS based on process type; "off" for 32 bit processes and "on" for 64 bit processes. In any case, I am going to reset it to "0" and do some more testing.

I can't believe MS would disable this setting as part of their Meltdown/Spectre patches. Just the opposite I would believe. You want to randomize over the largest address space available to minimize the odds of a predictive memory hit.

-EDIT- Unless .......... the API's associated with ASLR high entropy memory access are associated with Spectre/Meldown attacks and MS disabled it's use for this reason? I remember reading that MS disabled a new Win 10 1709 feature that enabled faster processor access to OS predictive memory areas. OMG could this be the "feature" they are referring to?

This would also explain why my AMD x64 built is actually running faster now than it did prior to the MS OS patches. It is randomizing x64 allocated process memory over a smaller address space coupled with the fact that AMD processors until the most recent, never employed the sophisticated predictive memory algorithms that Intel processors have used for many years. All this leads to the "$64,000 question." Should ASLR high entropy be re-enabled for older AMD processors?

 

Making some progress. Here is the mitigation MS added to Win 10 1709 to mitigate the Spectre - variant 2 exploit:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880(v=vs.85).aspx

That is all the info available. No configuration options, etc.. As such, it appears this has to be set at the program level and MS is keeping that a closely guarded secret. This is what they set for all their supported apps; IE11, Edge, etc.. As it stands right now, I see no MS mitigation at the program level for Spretre - variant 1. This also strongly implies that anyone not on Win 10 1709, is not fully protected against Spectre - variant 2.

As far as WDEG ASLR high entropy goes, appears that has to be set on at the system level via a MitigationOptions reg. value of "1." I still have no clue why mine was set to the disabled value of "2." Or, my previous assumption that a value of "0" will cause the OS to dynamically change it to a value of "1" or "2" depending on whether the program to be loaded is 32 or 64 bit.

 

You can install Firefox 4 and there would be no difference, because code is compiled and executed on server. Every browser is going to display the same result.
Unclear is printed, because server's CPU is heavily loaded and this exploit gives you the most probable character.

 

But are we really sure that the Test crashes for the Microsoft Patch?


https://msfn.org/board/topic/177430-spectre_meltdown-erik-august-stephan-vanderkhof-poc/

@reasonablePrivacy
TH.

 

There's a comment toward the end on that thread in regards to the "Pecker" test:

In other words, you really can't test if you are vulnerable to Sprectre - variant 2 unless you run one of the spectre.exe POC downloads locally. And just how that would be done is at this point unclear. Again, the exploit is against a currently executing process. As such, spectre.exe would have to be targeted against your browser's .exe allocated memory that has been transferred to the OS predictive memory storage areas.

 

I now have a theory on what might have disabled WDEG ASLR high entropy on Win 10 1709. First, we have to review the sequence of events in regards to how the Meltdown/Spectre patches were rolled out.

On Jan 3., the first emergency patch was rolled out which is KB4058702 - changes to Win 10 1709 servicing stack. I believe one of the things this patch did was disable ALSR high entropy. Appears that this feature is directly tied into the enhanced predictive memory access methods MS built into ver. 1709.

Later, patch KB4056892 was issued which was the main Spectre - variant 2 patch to ver. 1709. Summarizing, what this patch did was enable this new mitigation, PROCESS_CREATION_MITIGATION_POLICY2_RESTRICT_INDIRECT_BRANCH_PREDICTION_ALWAYS_ON, referred to previously at the program level. I have see public postings that as many as 400 programs were updated for ver. 1709. All this makes sense so far since MS only wanted to adversely impact vulnerable Internet facing apps but keep indirect branch prediction enabled for non-vulnerable system and app processes to enhance overall system performance. Finally, I believe the last function of this patch was to re-enable ASLR high entropy.

If one refers to early postings in this thread, there was confusion in regards to the order in which KB4058702 and KB4056892 should be applied if one was performing the patches manually. I do know I initially applied KB4058702 first and KB4056892 second which was indeed the correct order they should be applied. Later based on posting recommendations in this thread, I uninstalled KB4058702 and then reinstalled it resulting in ALSR high entropy being disabled.

All the above leads me to believe that the performance issues some Wilders folks are currently experiencing on Win 10 ver. 1709 might be related to the above.

-EDIT- I also ran the Powershell commands to verify that the OS mitigation for Spectre -variant 2 is also still enabled proving that the resetting of ALSR high entropy system setting to a value of "0" had no impact on the mitigation.

 

UCyborg is strong !!
Now the program runs on my XP but also in the PC with W.10 x64.
I requested a change.

___________________________________________

Pc W.10 1709 x64 + patch
Pentium Dual Core E6700



Vulnerable.

 

@itman

How do you interpret this result?
Only 2 score = 2
XP Intel Celeron M380:



P.S.

4 types of test files available.
Those with "pause" can be launched without Command Prompt:

https://drive.google.com/open?id=1WG-62M9ZZwDXNf0xlhx6NhR-_gtDv7AC

 

What these stand-alone Spectre - variant 2 tests are showing is:

1. Your CPU is vulnerable.
2. It will remain vulnerable until a BIOS update is issued.

However, one would have already known most of this if they ran the Powershell test or any of the other third party tests available.

What these spectre.exe stand alone tests don't show is if a given app you are running is exploitable with the current OS and app patches applied. Presently, the only test I am aware of is the Tencent test here: https://xlab.tencent.com/special/spectre/spectre_check.html and I have no idea how reliable it is.

 

Which of the 2 CPUs?

That test is unreliable.

 

If both fail the spectre.exe stand-alone test, they are both vulnerable. Neither have been BIOS updated I assume?

Also as I have elaborated upon, I don't put a lot of faith in these spectre.exe tests since they are only attempting to read predictive memory areas associated with memory used by the process. Effectively reading predictive memory areas of another process is an entirely different matter as far as I am concerned.

 

Update to Disable Mitigation against Spectre, Variant 2
Link: https://support.microsoft.com/en-us...-disable-mitigation-against-spectre-variant-2

Apparently Microsoft created a patch to apply my registry tweak suggestion.

This is a big concern:

EDIT: Microsoft released this patch on a Saturday!

 

From: https://support.microsoft.com/en-us...ive-execution-side-channel-vulnerabilities-in

EDIT: Appears that FeatureSettingsOverrideMask is different from my suggestion, while FeatureSettingsOverride was the same. I don't fully understand FeatureSettingsOverrideMask since it was not fully documented initially and was suggested to keep at '3' initially.

EDIT2: The same document still suggests:

Therefore I am still unsure about FeatureSettingsOverrideMask.

EDIT3: SpecuCheck shows now difference with the results when comparing FeatureSettingsOverrideMask '3' to FeatureSettingsOverrideMask '1' with a reboot in between.

 

@WildByDesign Coming from another thread, I was just going to ask you if you thought this update, KB4078130, applied the manual tweak you had already suggested.

Based on the above, have you now reset FeatureSettingsOverrideMask from '3' to '1'?

I am having no issues with '3', but if so, I will do the same.

 

@itman

Hi
I got there late but I understood the operation of the instrument.
A calibration must be performed in the absence of any protection.
It is also possible to act on cache values.
Example:

spectre-sse2.exe 90

The output must be the one below:



When the instrument is calibrated, apply the protections and check.
TH @ UCyborg.

 

I decided to switch FeatureSettingsOverrideMask to '1' per the MS KB and have kept it at '1'. However, I found the end result to be exactly the same whether it was on '3' or '1'. It seemed to make no difference with the results on SpecuCheck and the problem was resolved using either.

 

InSpectre Release #6 v0.0.6601.6 (January 27, 2018)
Website
What's New:

 

Someone over at GitHub has developed a Meltdown/Sprectre status utility in the form of a PowerShell script that will also inform if your browser has been patched for Spectre - variant 1. Note: I have not run this myself, so proceed with caution.

https://github.com/vrdse/MeltdownSpectreReport