System-wide Mandatory ASLR Failure to Properly Randomize (Win8+)

Great job itman.

But even EMET 5.5 + W.10 (1607) then had to be in the same condition.
My test (post 76) was done in 2016.
"Exploit Test Tool" same version of the current one.

W.10 1607

 

Here's a write up of Sophos's Intercept-X exploit protection which is in reality HMP-A: http://www.sophos.si/media/files/000/000/228/original/comprehensive-exploit-prevention-wp.pdf. The write up also is a detailed explanation of individual tests performed in the latest HMP-A Test Tool.

Specifically refer to the section on "dynamic heap spray" protection. It is fair to assume the heap spray tests being performed by the current test tool are dynamic heap spraying ones. Appears these tests are specifically designed to avoid Win 10 CE guard page triggers.

The other section of the write up to note is the new SysWOW64 protections/tests. Notable is anything running from the SysWOW64 directory are not true 32 bit processes but actually run in 32 bit compatibility mode instead. I tested WDEG detection against the two HMP-A Test Tool tests for it using notepad.exe. WDEG will detect ROP - Wow64 bypass, but not ROP - Exploit Wow64. The later test is bypass 32-bit ntdll via fs:[0xc0]. I specially enabled the WDEG heap mitigation in notepad.exe for these tests. This was the possible reason WDEG did detect the first test since the exception code for the abend indicated a memory violation. It may be possible to pass the second test by setting on additional WDEG app mitigations. Also when testing SysWOW64 directory based apps, make sure you use the specific app in the test tool.

-EDIT- I forgot to mention that the WDEG heap mitigation at the app level only needs to be enabled for SysWOW64 directory processes. If you add the app to WDEG by name only for notepad.exe for example, I would then enable the heap mitigation although it is N/A for the 64-bit ver. of notepad.exe. Questionable is why it is not enabled for other system processes such as svchost.exe since a 32-bit app could install a 32-bit service.

 

I noticed some issues with regard to Windows Defender Exploit Guard (WDEG) and using it's Export option which saves the kernel level MitigationOptions as well as the IFEO (per-app) MitigationOptions to an XML file. I had specifically set the ASLR and Bottom-Up ASLR system-wide per the CERT reg file import. I was doing my regular backup (Export) of settings via WDEG and the problem was upon import. WDEG doesn't quite have an Import feature yet, though it can be done via GPO I believe. I often do the export/import via PowerShell ProcessMitigations module (built-in) anytime I make changes.

Anyway, upon import, it essentially changed the 1's for ASLR and Bottom-Up ASLR to 2's and therefore I had to import the CERT reg file again to fix it. I don't know whether the error was within WDEG Export to XML function or the Import via PowerShell ProcessMitigations module. Regardless, there is definitely some more fine tuning to do within the WDEG app and import/export functionality.

 

MBAE passes Heap tests in my XP (2/3).
Even if the intervention is for ROP mitigations.
WDEG should at least do the same.

 

I agree. However as posted in reply #79, don't expect the old EMET heap spray protection to be added. Also, the old EMET protection only protected limited memory locations although those could be expanded via user override.

Appears MS is putting "all their memory protection marbles" in ASLR which as most security experts have publically stated is insufficient protection. Add to this the JavaScript side-channel memory exploit POC for which no known mitigation currently exists.

 

Now that I am done testing WDEG, I will make this comment. I really don't know why anyone in there right "security mind" would use it. The hassle required to configure your apps, let alone one app is not worth the effort. Add to this the fact that WDEG can't block a number of the HMP-A Test Tool tests. I can configure one rule in Eset's HIPS to block process modification and it will trigger on every one of the new HMP-A Test Tool tests. Actually, you need a few more rules such as monitoring script and cmd.exe execution. I then just create allow rules for trusted Win processes that do process modification to HIPS protected processes and I am done. Finally since bypassing Win 10 CE protected processes is no big deal, HIPS monitoring of those processes corrects that deficiency.

 

WDEG is to be improved.
But is integrated into the OS.

 

Has Microsoft fixed the issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that prevents system-wide enablement of bottom-up randomization?