Jump to content
hake

The value of bottom-up ASLR in Windows XP

Recommended Posts

Will someone please give me a single syllable response as to whether there is any beneficial use for bottom-up ASLR in Windows XP.  I guess that any entropy in allocation of memory is better than none.  Is that guess correct?

Edited by hake

Share this post


Link to post
Share on other sites

In a single syllable -

Que?

Share this post


Link to post
Share on other sites

This is a serious question and I am disappointed that no 'yes' or 'no' confirmation is forthcoming.

Edited by hake

Share this post


Link to post
Share on other sites

Sorry I didn't/don't understand the question myself, it may have been better in a different sub-forum wher more people might see it, General PC Help perhaps.

I've reached out to others to see if they can help.

Edited by nukecad

Share this post


Link to post
Share on other sites

I believe the OP is asking if, since ASLR is a feature implemented starting in Windows Vista by Microsoft and didn't exist in Windows XP, is there any point to this setting/function in Malwarebytes Anti-Exploit when running on Windows XP, and I believe the answer is "no" since there is no system default ASLR to be enforced, at least if I am understanding Malwarebytes' implementation of this feature correctly in that I believe, just as with their DEP enforcement feature, it relies on the system's in-built functionality to work and simply augments/enforces the system's function as implemented by Microsoft in Windows.

For reference:

https://en.wikipedia.org/wiki/Address_space_layout_randomization#Microsoft_Windows

Share this post


Link to post
Share on other sites

Microsoft's EMET 4.1 appears to allow the enabling of bottom-up ASLR for Windows XP and also specifically excludes the option of enabling ASLR for Windows XP.  I have assumed that this implies that bottom-up ASLR has some minimal effect with XP.  Otherwise why would Microsoft have discriminated between ASLR and bottom-up ASLR for XP in EMET 4.1?

Share this post


Link to post
Share on other sites

Me?  Correct?*!?*!?  I have never been correct in my life. Hear my friends laugh when they read this thread.

I just wanted to have the satisfaction of confirmation that my beloved XP enjoys some, even if limited, additional protection by bottom-up ASLR.

Edited by hake

Share this post


Link to post
Share on other sites

Hey, you never know.  I assumed that because MS hadn't added that feature until Vista (and I believe it's also exclusive to x64, though I may be wrong on that point) that it didn't apply to XP, but if they did it in EMET then perhaps they did it in MBAE/MB3/MBAM as well.  I'll make a note of it and ask the Product team and get you an answer for sure one way or the other.

Share this post


Link to post
Share on other sites

Yes, I know.  I wasn't saying that DEP was exclusive to Vista+, just that it was a built in function in the OS implemented by Microsoft just like ASLR.

Share this post


Link to post
Share on other sites

EMET 4.1 Uncovered (http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf, 2013-11-18) says "Bottom-up randomizes the heap by making a random number of allocations when the process starts up.  This is effective for adding some randomization to the heap to old OS’s, but has no impact for newer operating systems."

Each time a process starts up, new allocations are made. This why bottom-up ASLR is apparently so important for Windows 7.  Bottom-up ASLR has only 8 bits of entropy but that additional entropy is a considerable strengthening of secuity for Windows 7.  If it also applies to heap allocations in Windows, 8 bits of entropy is better than none.

That is my take on bottom-up ASLR for what it's worth.

Share this post


Link to post
Share on other sites

I wonder if any of WehnTrust's features should be incorporated into Malwarebytes. It could potentially improve security with its SEH Overwrite Protection, its Format String Vulnerable preventions, and its own ASLR capabilities, especially on older versions of Windows. And it's open source, which is really nice and makes adapting its features seem a lot more viable to me.

https://archive.codeplex.com/?p=wehntrust

Another security feature which is similar to Bottom-Up ASLR which could be a good supplement is Library Load Order Randomization (though that might require changes to the OS on Microsoft's part).

Further still, additional security measures such as Shadow Stacks and Random XOR Canaries could both also be used to compliment ASLR if they haven't already been worked on.

https://en.wikipedia.org/wiki/Buffer_overflow_protection#Random_XOR_canaries

https://en.wikipedia.org/wiki/Shadow_stack

One way to offset the potential compatibility problems of using Shadow Stacks; you could notify the user every time a program encounters an error as a result of an exception or a longjmp.

Also of note for ASLR; making the program and drivers PAE aware and allowing then to use large memory pages could be used augment ASLR on Windows XP and Windows Server 2003 on systems with at least 4 Gigabytes of RAM (even if most of the operating system is unable to use it in the case of the 32-bit version of XP). And while it wasn't explicitly designed for security, experimenting with a Ravioli Memory implementation (which I made a thread about in General Discussion) might possibly have ancillary security benefits on top of avoiding memory fragmentation and providing more robust management of system resources.

Now in response to @exile360, I was merely trying to point out that you seemed omit XP SP2 on the list of supported operating system for DEP. I'd like to share some final thoughts on that subject; though Data Execution Prevention is great,  better implementations do exist which allow even more flexibility, such as separating the bits for Write Access and Execution Access, and/or separating the bits for Privileged and Unpriviledged Execution, or even enforcing Sandboxed Execution. However, those various implementations are only supported in-hardware on non-x86 architectures, and even then, not all of those support the same features, and I'm not certain how viable software-based implementations could be without at least a partial rewrite of the operating system itself.

Share this post


Link to post
Share on other sites

Someone else will have to do it for any OS older than 7 as Malwarebytes only officially supports Windows 7 and newer Windows versions now and won't be developing any new features for Vista or XP.  They do still provide the last compatible version of Malwarebytes for those operating systems for download, but that's it.

Share this post


Link to post
Share on other sites

From the studying that I have now undertaken, on a balance of probabilities it appears to be highly likely that XP does benefit from the enabling of bottom-up ASLR.

For my very old XP systems without SSE2 enabled processors, I have reverted to using EMET 4.1(update1), Comodo Memory Firewall and a very fully enabled OSArmor 1.4.2 as a backstop which works a treat with my museum pieces. Sure it's not watertight but there are plenty of layers of defence and I have yet to experience even a single intrusion in almost 15 years of running these two venerable XP systems (both been running as the same incarnations since they were installed early in 2004). Agnitum Outpost Firewall Pro has figured continuously over than time.

I would not be without MBAE on recent technology but it's nice to tinker with well backed-up stone-age systems which are not used for critical purposes. I am toying with the idea of increasing the steam pressure on them and am looking for a supply of better quality coal. An automatic stoker would be good.

Edited by hake

Share this post


Link to post
Share on other sites

@Amaroq_Starwind:  After previous abortive attempts at getting WehnTrust 1.20 to work on my 15 year-old incarnation of Windows XP SP3, I made another attempt today and, blow-me-down, it works!  In fact it works very well with only a small speed reduction.  I notice that it is only said to detect stack overflows whereas Comodo Memory Firewall boasts that it also detects heap overflows.  Does ASLR trump detections of heap overflows?

WehnTrust does ASLR, SEH overwrite protection, stack overflow protection and format string protection.
Comodo Memory Firewall does stack AND heap overflow detection, detection of ret2libc attacks and detection of corrupted/broken SEH chains.

Note that WehnTrust uses the term 'protection' whereas Comodo Memory Firewall uses the term 'detection'.

Which of the two products gives better protection?   I would be grateful for your opinion.

URGENT UPDATE WehnTrust has incompatibilities with MBAE. Do not use WehnTrust or applications will be damaged.

The problem lies in the effects on WehnTrust on the internal behaviour of older applications which causes MBAE to detect issues which were not detected when WehnTrust was not in use. This additionally breaks older applications such as Office 97, 2000 and 2003 which malfunction at attempted subsequent use such as losing dlls. The only way to regain their use appears to be their reinstallation. I don't think Windows XP itself is damaged as newer applications survive to run another day and Windows does not display any error message boxes

Less common occurrences of similar issues happen when EMET 4.1 is used instead of MBAE.

I managed to find out that WehnTrust ASLR only has 19bits of entropy. Enabling bottom-up ASLR does not of itself appear to create additional problems.

Edited by hake

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.