ZeroHour
Security Affairspublished ()ingested @securityaffairs

Windows 8 and newer versions fail to properly implement Address Space Layout Randomisation

mediumVulnerabilityimportance 35CVE-2017-11882

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2017-11882
Memory Corruption RCE in Microsoft Office via Legacy Equation Editor

CVE-2017-11882 is a memory corruption vulnerability (CWE-119) in Microsoft Office, residing in the legacy Microsoft Equation Editor component (EQNEDT32.EXE), that allows remote code execution in the context of the current user. Attackers trigger it by persuading a user to open a crafted document, most commonly an RTF file or other Office document carrying a malicious embedded equation object, which overflows a buffer while the equation content is parsed. Successful exploitation lets the attacker run arbitrary code with the privileges of the signed-in user, a typical foothold for malware delivery and, per CISA, for ransomware operations. Any environment running affected Microsoft Office builds is exposed; the source data does not enumerate specific affected version ranges. The flaw is confirmed exploited in the wild: it was added to the CISA Known Exploited Vulnerabilities catalog on 2021-11-03 with known ransomware use and holds a 99.9% EPSS score (percentile 100), though the source data lists no public PoC.

Do: Apply Microsoft's Office security updates (November 2017 or later) across all endpoints, prioritizing this KEV-listed flaw given its known ransomware use. On systems that cannot yet be patched, disable or unregister the legacy Equation Editor (EQNEDT32.EXE) and consider blocking or warning on RTF attachments as interim mitigations. Check for indicators of abuse such as EQNEDT32.EXE spawning unexpected child processes after document opens.

7.8100% KEV ransomware PoC ×10
  • Microsoft Office
masshundreds of millions of users/installations (Office is near-ubiquitous on Windows and in enterprises; the share still unpatched is unknown)
Full article703 words · extracted from securityaffairs.com · click to collapse

Pierluigi Paganini November 21, 2017

CC/CERT is warning the Address Space Layout Randomisation (ASLR) isn’t properly implemented in versions of Microsoft Windows 8 and newer.

The researcher Will Dormann from the Carnegie-Mellon CERT has discovered the Address Space Layout Randomisation (ASLR) isn’t properly implemented in versions of Microsoft Windows 8 and newer.

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.
Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

The Address Space Layout Randomization (ASLR Protection) is a security mechanism used by operating systems to randomize the memory addresses used by key areas of processes, it makes hard for attackers to find the memory location where to inject their malicious code.

The Address Space Layout Randomisation is particularly effective against stack and heap overflows and is able to prevent arbitrary code execution triggered by any other buffer overflow vulnerability. The security measures are present in almost any modern operating system, including Windows, Linux, macOS, and Android.

Applications running on Windows 8 and newer versions were allocated addresses with zero entropy, this means that it was possible to predict where the code is allocated in memory due to the failure of the randomisation. Windows 10 has the problem, too.

The CERT/CC published a security advisory late last, Dormann found the ASLR issue while he was analyzing a recently fixed bug in Microsoft’s equation editor, tracked as CVE-2017-11882, that could be exploited by remote attackers to install a malware without user interaction.

“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 randomise executables that do not opt in to ASLR.” states the security advisory.

According to the CERT, the bug only affects applications using mandatory ASLR, while applications that used opt-in Address Space Layout Randomisation and that never used ASLR aren’t affected.

According to the CERT/CC the problem was introduced with Windows 8 with a change in the mandatory Address Space Layout Randomisation implementation.

“Starting with Windows 8, system-wide mandatory ASLR is implemented differently than with prior versions of Windows. With Windows 8 and newer, system-wide mandatory ASLR is implemented via the

HKLM\System\CurrentControlSet\Control\SessionManager\Kernel\MitigationOptions 

binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system -wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.” continues the advisory.

The CERT explained that both EMET and Windows Defender Exploit Guard can enable mandatory Address Space Layout Randomisation for code that isn’t linked with the /DYNAMICBASE flag.

“Both EMET and Windows Defender Exploit Guard enable system-wide ASLR without also enabling system-wide bottom-up ASLR. Although Windows Defender Exploit guard does have a system-wide option for system-wide bottom-up-ASLR, the default GUI value of “On by default” does not reflect the underlying registry value (unset).” states the advisory.

“This causes programs without /DYNAMICBASE to get relocated, but without any entropy. The result of this is that such programs will be relocated, but to the same address every time across reboots and even across different systems.”

Or for those not proficient in setting bits in binary registry values (such as myself), either manually set the values indicated in this picture, or if you don't care about clobbering any existing system-wide mitigations, import this .REG file:https://t.co/nOnhvU2xZF pic.twitter.com/i4YNpET0wq

— Will Dormann (@wdormann) November 16, 2017

Dormann explained that sysadmins can set a registry value to force bottom-up Address Space Layout Randomisation.

“The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workaround:
Enable system-wide bottom-up ASLR on systems that have system-wide mandatory ASLR

To enable both bottom-up ASLR and mandatory ASLR on a system-wide basis on a Windows 8 or newer system, the following registry value should be imported:
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" concludes the CC/CERT
[adrotate banner=”9″] [adrotate banner=”12″]

Pierluigi Paganini

(Security Affairs – Microsoft, ASLR Protection)

[adrotate banner=”5″]

[adrotate banner=”13″]



Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/65828/hacking/address-space-layout-randomisation-windows-8.html