Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10 - gHacks Tech News

Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10

If you use Microsoft EMET on Windows 8.x or Windows 10 machines, or the new Windows Defender Exploit Guard on Windows 10 version 1709, your system may not have been protected properly by a protective feature called Address Space Layout Randomization (ASLR).

Security researcher Will Dormann of the CERT/CC discovered an ASLR implementation issue on Windows 8 and Windows 10 machines.

Microsoft introduced ASLR in Windows Vista to prevent code-reuse attacks by randomizing the addresses that executable files were loaded in on the operating system.

While applications can make use of ASLR directly, Microsoft EMET could be used to add system-wide or application-specific support for ASLR on Windows machines.

microsoft emet 5.5 beta

Microsoft announced plans to retire Microsoft EMET recently, and added exploit protections to the company's Windows 10 Fall Creators update version of Windows 10 as a substitution.

According to the disclosure on Cert.org, Microsoft introduced a change in the handling of ASLR. Basically, what Microsoft did was add another requirement so that system-wide ASLR required system-wide bottom-up ASLR as well.

Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomize executables that do not opt in to ASLR.

The effect is problematic from a security point of view as the address of applications becomes predictable even if system-wide ASLR is enabled via EMET or Exploit Guard in Windows  10 Version 1709.

Luckily, there is a workaround for the issue. All that needs to be done is enable ASLR and bottom-up ASLR on the target machine to fix the issue.

Note: It is recommended that you back up the Registry before modifying it. Also note, that importing the value will overwrite any system wide mitigations specified by the Registry value.

This is done by importing the following Registry value:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

You can do this the manual way, but it is faster if you create a Registry file and import it instead. We have created the Registry file for you, so that you only have to double-click on it to import the data.

Download it with a click on the following link: aslr.zip

Just extract the downloaded archive, and double-click on the Registry file to import the data in the Registry. You can open the file in any plain text editor first to evaluate what it does before you do so. (via Born City)

Summary
Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10
Article Name
Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10
Description
If you use Microsoft EMET or the new Windows Defender Exploit Guard your system may not have been protected properly by a protective feature called Address Space Layout Randomization (ASLR).
Author
Publisher
Ghacks Technology News
Logo
Advertisement

We need your help

Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats or subscription fees.

If you like our content, and would like to help, please consider making a contribution:


Previous Post: «
Next Post: »

Comments

  1. Rick said on November 20, 2017 at 5:14 pm
    Reply

    Everyone will just run to implement the Registry change, but I think it’s a little more nuanced than that. Martin, maybe you can clear this up.

    The key phrase in the source article for the Registry change is: “Enable system-wide bottom-up ASLR **on systems that have system-wide mandatory ASLR**.”

    I just checked Windows Defender Security Center on 1709, and of all the related settings, Mandatory ASLR is the only one defaulting to OFF. So, 1709 out of the box does not meet the above statement.

    I have to wonder why Mandatory ASLR is off by default. MS might have a good reason to do so, like application compatibility. I’m assuming that if you want it ON though in 1709, Windows Defender Security Center is the place to do it.

    That action may or may not be in place of the Registry change, it’s unclear. Maybe you should also do the Registry change. But my point is that it maybe shouldn’t be on at all.

  2. WD said on November 20, 2017 at 5:34 pm
    Reply

    The registry file in this article enables both system-wide mandatory ASLR (the second byte, which is ‘0x01’), and system-wide bottom-up ASLR (the third byte, which is ‘0x01’). So importing the registry change will indeed enable proper system-wide mandatory ASLR with the entropy that it needs to function.

    1. Rick said on November 20, 2017 at 6:41 pm
      Reply

      The latter is already enabled on 1709, so is simply flipping Mandatory ASLR to its ON state via the UI in 1709 the same as implementing the .reg file? It sounds like you’re saying that it is.

      But, again, the question of why it’s off by default in 1709 must be raised (MS didn’t leave it that way accidentally). If applications need to be written for it, and they aren’t, what happens?

      1. WD said on November 20, 2017 at 10:21 pm
        Reply

        Bottom-up ASLR is *not* enabled by default in Windows 1709. Despite the Windows Defender Exploit Guard GUI telling you that it is, the underlying registry value is 0x00 (unset) in a clean Windows install. Toggling it off and then back on again will correct the underlying registry value.

      2. Rick said on November 21, 2017 at 2:32 am
        Reply

        @WD: There is no “MitigationOptions” (or “MitigationAuditOptions”) at all on a clean install–until you visit the UI to toggle things.

        How are you testing for the presence or absence of any of them when there’s no Registry value to check against?

        However, once you toggle one off/on, “MitigationOptions” is all zeroes.

      3. Rick said on November 22, 2017 at 11:46 pm
        Reply
  3. Sampei Nihira said on November 20, 2017 at 5:48 pm
    Reply

    My registry value at default (mandatory ASLR off + bottom-up ASLR on) is:

    01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

    the correct value should be

    01,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00

    Correct?

  4. James T. said on November 20, 2017 at 6:28 pm
    Reply

    It took three full operating systems to figure this out
    Was someone asleep at the wheel at M.Soft or will we find out later from WikiLeaks?

  5. chesscanoe said on November 20, 2017 at 8:08 pm
    Reply

    For an expansive understanding of this problem and limitations on trying to circumvent it, see
    https://www.kb.cert.org/vuls/id/817544 .

  6. InGSoC said on November 20, 2017 at 10:45 pm
    Reply

    Hello, activated Exploit Protection in Windows Security Center is NOT enough?

    But i am sitting behind a Routerfirewall + Windowsfirewall + Panda Security including Heuristicanalysis and Processmonitor.

    Never had any issues since Panda installed, so System is clean and smooth.

    Why is there a Reason to use Emet, if it is already implemented in WSC in Windows 10?

    I guess i am safe.

    Greets, InGSoC.

  7. fred said on November 21, 2017 at 2:46 am
    Reply

    Once the option was enabled I have already discovered a few random exe that completely refuse to run

  8. Noob said on November 22, 2017 at 12:46 pm
    Reply

    Confirming that this “fix” ruined WordPress desktop app and it cannot start.

    1. FirehawkV21 said on November 23, 2017 at 7:26 am
      Reply

      Some apps don’t support ASLR properly. Forcing ASLR breaks them.

  9. TelV said on November 23, 2017 at 2:02 pm
    Reply

    Windows Defender is disabled and I don’t have EMET installed so I assume my 8.1 system isn’t vulnerable. Have I got that right?

    By the way, when I click the Submit button the page hangs with “Read pagead2.googlesyndication.com” appearing bottom right of the browser (Basilisk). Ctrl+F5 clears it.

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

Please note that your comment may not appear immediately after you post it.