The entropy for force relocated images comes from bottom-up ASLR which is only enabled by default if the EXE was built with /dynamicbase. Try turning on bottom-up ASLR as well.
-
-
Thanks. I'm pretty sure that Bottom-up ASLR is enabled along with Mandatory ASLR. But eqnedt32.exe is always loaded at the same location.pic.twitter.com/zFgmbByCEP
1 reply 0 retweets 0 likes -
I believe "on by default" means "use the default system policy" which means bottom-up ASLR will only be enabled if the EXE was linked with /dynamicbase (which this one does not, I believe). Sound right,
@markwo?3 replies 0 retweets 1 like -
Yeah, that's right. I was seeing what Will describes last night until I enabled bottom-up ASLR for this process in Exploit Guard
1 reply 0 retweets 0 likes -
Is there any way to enable Bottom-up ASLR on a system-wide basis? If not, then it would seem that Mandatory ASLR only really adds protection for apps that opt in. Which seems sort of non-Mandatory to me...
1 reply 0 retweets 3 likes -
It is possible to enable bottom-up ASLR system-wide, but I'm not sure if it can be done via the WDEG UI,
@markwo might know. Agree with your feedback here. I passed it on to the team.1 reply 0 retweets 2 likes -
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
4 replies 60 retweets 100 likes -
For those of you catching up on this thread, MSRC has published a blog post clarifying the behavior that was observed here and how to workaround it:https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ …
1 reply 7 retweets 14 likes -
Replying to @epakskape @SwiftOnSecurity and
As a user, our IT had forced ASLR and random chrome tabs became unusable, some apps just wouldn't work, and the way cygwin shells fork to create new processes would just insta SEGFAULT. These were company supported apps. Please be careful with ASLR.
1 reply 0 retweets 3 likes -
Replying to @boondaburrah @epakskape and
This behavior of Cygwin has been known for years. It was suggested that hell would sooner freeze over before it were fixed. https://cygwin.com/ml/cygwin/2013-06/msg00096.html … If you need your GNU fix on a locked-down Windows system GOW seems to work fine (minus bash.exe).https://github.com/bmatzelle/gow/wiki …
1 reply 0 retweets 1 like
Will Dormann Retweeted Will Dormann
And apparently I had first noticed this years ago. I imagine that getting ASLR support in Cygwin is not anybody's priority.https://twitter.com/wdormann/status/477161240327094273 …
Will Dormann added,
-
-
Replying to @wdormann @epakskape and
Based on what I saw ASLR + cygwin may be actually impossible due to the way the fork() syscall is supposed to work in POSIX.
1 reply 0 retweets 1 like -
Replying to @boondaburrah @wdormann and
What drove me nuts is the corp forced on ASLR and also had cygwin as part of it's standard available packages. I don't know if they tested.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.