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

Discussion in 'other security issues & news' started by WildByDesign, Nov 17, 2017.

  1. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    I ran the following heap spray code within IE11 x64:
    http://www.fuzzysecurity.com/tutorials/expDev/8.html

    And not a peep from WDEG:

    Heapspray_Test.png
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    I tried the below more advanced heap spray script from the above posted link against 32 bit IE11. This script does overflow the allocated memory pool. Also not a peep from WDEG heap spray protection:
     
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Been doing some research into WDEG heap spray protection and believe I have a possible explanation for why the HMP-A Test Tool heap spray tests are failing.

    First, WDEG heap spray protection is not the same as EMET's was as noted below:
    From the above, it is obviously that select memory areas are not longer monitored for tampering with as done with EMET.

    So just what is WDEG heap protection:
    Ref.: https://docs.microsoft.com/en-us/wi...ations-in-windows-10#windows-heap-protections

    Let's analyze what has been posted above. Microsoft considers EMET heap type protection unnecessary since malware using such heap spray exploit techniques are rare and not a major factor in exploit methods.o_O:rolleyes::shifty: Whether the heap guard page protection works will have to be proven and one malware heap spray successful bypass throws it out the window; baby and bath water included.

    Presently, it appears the HMP-A Test Tool is not appropriate for testing WDEG heap spray protection; at least on 32 bit processes? Or as I strongly suspect, heap guard pages aren't used to protect the memory of 32 bit processes.
     
  5. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    Stack Exec has now failed as EMET has passed.

    @itman

    Some theory about it?
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    The WDEG validate stack integrity check is for Stack Pivot only per MS documentation. Every test I have performed to date using HMP-A Test Tool regardless of app tested has failed the Stack Exec test. This includes the 32 and 64 vers. of the test tool. So assume WDEG does not protect against it.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    I found the WDEG equivalent of EMET's heap spray protection.

    It is arbitrary code guard(ACG) and it is only validate for 64 bit processes running on 64 bit Win 10 RS3; a bit more on this latter. You can read about ACG and code integrity guard(CIG) which is a complementary protection here: https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/ . Note: if you are using a third party AV solution that injects its .dlls into your browser, enable auditing on the CIG mitigation. Then check the Windows Security -> Mitigations -> user event log for warning messages about its .dlls being blocked from loading. If so, you can't use CGI since it will only allows MS, WQL, and higher signed .dlls to be injected. Also noteworthy is you won't find an app entry for Edge in WDEG. This is because both ACG and CIG are automatically built into it.

    I set the ACG mitigation on for my ver. of Abode Reader which is 32 bit. The result was that Windows Security -> Mitigations -> kernel event log container over 1000 entries stating that "dynamic code injection would be prevented" immediately after the start up of Adobe Reader.:eek: This was a clear indication that ACG went "bonkers" when interpreting 32 bit process memory allocation.

    So the above validates why heap spray was detected when using the 64 bit ver. of the HMP-A Test Tool. Bottom line - if you are using a 32 bit app on 64 bit Win 10 RS3, you at not protected against a heap spray attack against it. Whether the same above behavior occurs on 32 bit Win 10 RS3 will have to be determined by someone using it.
     
  8. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    Enabling ACG mitigation for a 32 bit exe in a 64 bit OS equates to prevents the software from starting.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Actually, Adobe Reader ran OK with it enabled aside from the multitude of event log entries for it.
     
  10. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    http://sendvid.com/cvc8jpj0

    ;)
     
    Last edited by a moderator: Nov 30, 2017
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    This is weird.

    If you enable auditing for ACG, Abode Reader runs w/o issue other than all the log entries mentioned previously. If you disable auditing for ACG, then Abode Reader won't start as your video shows. Personally, I think WDEG is a piece of crap
     
  12. hiten

    hiten Registered Member

    Joined:
    Oct 20, 2007
    Posts:
    27
    Hi all, can anyone help me?

    When I checked Windows Defender GUI, my current config is Mandatory ASLR off + bottom-up ASLR on (the default configuration).
    MitigationOptions didn't exist on regedit.

    I tried using the GUI to toggle Mandatory ASLR on and off again then reboot, after that regedit shows MitigationOptions.
    But the value of 2nd and 3rd byte is 02 and 00.

    Windows Defender GUI still display Mandatory ASLR off + bottom-up ASLR on. But why does my registry show 02 00, isn't it supposed to be 00 01 ?


    Clipboard 2.png
     
    Last edited: Dec 1, 2017
  13. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    :argh:
    Strange also that there is still no official test on WDEG
    We could write to Andreas Clementi (AVC) to request it.
     
    Last edited: Dec 1, 2017
  14. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    Try to change the registry value manually.
     
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Assuming the OP only did as stated and toggle the WDEG system-wide mandatory ASLR on and off, is there an unknown system-wide mandatory ASLR setting of "2" no one is aware of? And is this possibility "the root" of our heap spray failures on 32 bit processes?
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Was there ever one for EMET? I am not aware of any. If you know of one, post link to it and we can try it against WDEG.
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Microsoft actually did develop a test tool for EMET; at least ver. 5.2. You can download the documentation for it here: https://www.microsoft.com/en-us/download/confirmation.aspx?id=48240 . Only works through Win 8.1 and requires Win Server 2012 RS2.

    l also realized that EMET set hooks in guarded processes. So any test tool for it would be N/A for WDEG.
     
  18. hiten

    hiten Registered Member

    Joined:
    Oct 20, 2007
    Posts:
    27
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\

    Keyname is MitigationOptions

    I tried to google this and found this page: https://support.microsoft.com/en-us...iew-adds-a-feature-that-blocks-untrusted-font

    According to that page, this key is also used to block Untrusted Fonts. And 2 is used to turn the feature off. Is it possible that ASLR also use the same format?
     
  19. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,154
    Location:
    Toronto, Canada
    One point of confusion here might be the fact that there has been a change to the format of the MitigationOptions regkey from previous QWORD (64-bit) Value to REG_BINARY (Binary format) part way through Windows 10 development cycle.

    The reason for this was because they simply ran out of MitigationOptions bits. There were too many mitigation options and therefore switched to REG_BINARY (Binary format) to accommodate the addition of all of the ROP mitigation options that were brought over from EMET directly to kernel level. Better performance and more MitigationOptions bits to flip. Also there is still room for more mitigation options to be added in the future as necessary. For example, Return Flow Guard, potentially.

    Some good examples of the good old MitigationOptions QWORD format: https://theryuu.github.io/ifeo-mitigationoptions.txt
    * that is missing a few, but essentially explains things well
    * also explains 1 for enabled, 2 for disabled, etc.

    Now with RS3 (1709), we have REG_BINARY (Binary format) with the possibility of supporting many more mitigation options and room for future expansion.

    In RS3 (1709), it can still support MitigationOptions QWORD format, for those interested. You can use either QWORD, following that older format and bit assignments, or you can use the new REG_BINARY (Binary format) following those slightly different bit assignments which you can follow my research spreadsheet for. The bit assignments are slightly different and therefore could cause some confusion. You cannot use both QWORD and REG_BINARY (Binary format) at the same time though.
     
  20. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,154
    Location:
    Toronto, Canada
    I should note that GFlagsX (https://www.wilderssecurity.com/threads/gflagsx-with-mitigation-options.394921/) can be used to easily manipulate the old QWORD MitigationOptions format. GFlagsX does not support the newer REG Binary format yet though and that is where my research spreadsheet comes into play to assist the developer of GFlagsX since much of the bits are not documented. GFlagsX will crash if there are any REG Binary format keys.
     
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    I finally got heap spray detection for a 32 bit process to work - sort of. It works for the old 32 bit HMP-A Test Tool; not the latest ver. So I assume the new ver. has an issue with RS3.

    I also found out how WDEG works internally. The default system mitigations for RS3 64 bit OS apply to 64 bit processes only. For 32 bit processes, those have to be manually set on at the app level. So DEP, the two ASLR settings, SEHOP, and heap spray all have to be enabled for 32 bit apps you use. I can't explain why heap spray default setting is currently not overridden in Firefox and Thunderbird. I believe it should be.
     
    Last edited: Dec 2, 2017
  22. hiten

    hiten Registered Member

    Joined:
    Oct 20, 2007
    Posts:
    27
    Thank you all for the detailed explanation.
     
  23. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    870
    Location:
    Italy
    WDEG is definitely to be improved.
    We could report these "bugs" to someone who takes care of the project.
    I know Gerardo di Giacomo but I think it's .................out !!

    Miller I do not know him and in the page you can not comment.
     
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    I did some more testing and I have some bad news. My assumption was erroneous that because the old 32 bit test tool was detecting heap spray, the WDEG heap mitigation was the reason it did so.

    I disabled the WDEG heap system mitigation and rebooted. Verified that it was indeed disabled by noting the corresponding mitigation reg value for it was set to "2." I then reran the 32 bit test tool heap spray tests. Guess what? The first two tests work as previously.:eek: So whatever WDEG heap mitigation is, it has nothing to do with detecting app heap spray activity.

    At this point, I can only conclude that WDEG heap mitigation applies to system processes only. I believe an override for it exists at the WDEG app level primarily for disabling it when there is a conflict with a current running system process. I believe the latest HMP-A Test Tool ver. accurately reflects this lack of the old EMET app level heap spray protection in WDEG. Of note is the app level WDEG heap mitigation is only enabled by default for one process, PresentationHost.exe which is indeed a system process. This most likely is because it was excluded from heap protection for some reason in RS3.
     
    Last edited: Dec 2, 2017
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    5,489
    Location:
    U.S.A.
    Here's an error event log excerpt from the old 32 bit test tool heap spray test:
    That exception code indicates a stack or buffer overflow.

    It appears test tool developer created new heap spray tests for the latest ver. and WDEG does not detect those. I suspect in these new heap spray tests, he does not overflow the stack or buffer.
     
Loading...