64-bit executable bug with Windows 10 exploit mitigation
-
There’s a bug causing the 64-bit executable to crash on Windows 10 with exploit mitigation. Reproduction:
1. Open the “Settings” app
2. Go to Update and Security -> Windows Security -> App and browser control
3. Select global settings, or create a separate setting for the Falcon BMS executable (not the launcher)
4. Enable “Randomize memory allocations (bottom-up ASLR)”
5. Enable “High-entropy ASLR” in global settingsRunning the 64-bit Falcon BMS executable with these settings will produce this stack trace:
[...] 0033:0000000004AF4830 Falcon BMS.exe, _findnext64i32()+44 byte(s), f:\dd\vctools\crt\crtw32\direct\findf64.c, line 287+10 byte(s), Parameters(0x00000000FFFFFFFF 0x0000000000000008 0x0000000000000001 0x00000000C879EB59) 0033:00000000044CE76E Falcon BMS.exe, ResCountDirectory()+574 byte(s), e:\wip\bms\svn\source\rel-4.33\codelib\resources\reslib\src\resmgr.c, line 3877, Parameters(0x0000000000000000 0x00000000C879EE20 0x0000000000000000 0x00000000C879F0FE) 0033:00000000044CDED4 Falcon BMS.exe, ResAddPath()+468 byte(s), e:\wip\bms\svn\source\rel-4.33\codelib\resources\reslib\src\resmgr.c, line 3429+17 byte(s), Parameters(0x0000000000000374 0x0000000000000000 0x000000005F0402CF 0x00000000000000FF) 0033:00000000044978ED Falcon BMS.exe, SetupResourceDirectories()+29 byte(s), e:\wip\bms\svn\source\rel-4.33\ui\src\winmain.cpp, line 1014, Parameters(0x0000000004BAC278 0x00000000C879F4E8 0x00000000C879F4B0 0x0000000000000002) [...]
I already know the workaround (exclude Falcon BMS from global ASLR). I’m only notifying you about a programming error. It probably involves a pointer-to-integer-to-pointer truncation (edit: MSDN likely culprit). Without ASLR, it works by accident. This is only a guess.
The issue isn’t critical given default exploit mitigation settings. It defaults to disabled probably due to exactly this kind of issues (pointer truncation). I haven’t observed crashes with any other 64-bit app running on my system however.
sh
-
Hi, this was checked and was dismissed as no bug at all. We’re explicitly setting the mem ASLR range to a fixed value.
-
Good to know that’s a false positive, thanks.
Edit: it appears like -DYNAMICBASE without -HIGHENTROPYVA. The exploit mitigation function can do other abusive things (other than forcing -HIGHENTROPYVA), like forcing -DYNAMICBASE for all processes. Go figure.
-
m$ strikes again…
-
m$ strikes again…
The exploit mitigation feature protects against perhaps a wider range of attacks than a typical Linux/BSD system. It’s commendable if anything.
The aforementioned Unix systems have even larger capability for shooting oneself in the foot. You remember how not to delete everything by accident by the fifth time it happens. And even then it happens occasionally. <nerd-talk>On Unix, try launching a subprocess with standard descriptors 0-2 inclusive closed and see the mess that happens.</nerd-talk>