Jump to content

hake

Honorary Members
  • Content Count

    427
  • Joined

  • Last visited

About hake

  • Rank
    True Member

Profile Information

  • Location
    Wigan, England
  • Interests
    Rugby League, Cricket

Recent Profile Visitors

6,841 profile views
  1. Previous aversion to https://www.dailymail.co.uk clickbait/scams (alleged) still present.
  2. I had to uninstall version 1.0.36 before successfully installing version 1.0.38. Now installed it seems no longer to assert its previous aversion to https://www.dailymail.co.uk.
  3. Why is it necessary to give permission for the Malware Firefox extension 1.0.38 to become active. Does this mean that until the user responds to the yellow alert over the three sausages (i.e. Open Menu) the extension is not protecting?
  4. @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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. This is a serious question and I am disappointed that no 'yes' or 'no' confirmation is forthcoming.
  10. 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?
  11. ??? The problem behaviour has ceased since the December Patch Tuesday updates were installed.
  12. I have two Windows 7 (x64) systems. Both run 32bit Google Chrome 71.0.3578.80. All browser extensions crash since MBAE 1.12.1.141 was installed. I installed 64bit Google Chrome 71.0.3578.80 and find that the 64bit version is unaffected. There was no issue with 32bit Google Chrome 70. When MBAE is disabled the issue ceases but I find that I need to restart the system to be sure.
  13. I hope that the MBAE team will in due course drop hints in the form of new 'advanced settings' options. I expect that all their resources are prioritised to providing their users with as effective protection for Google Chrome as the previous methods still in use for other browsers provide. Their ingenuity must be immense. Who knows that the new protections might be even better?
  14. Windows 7 users will appreciate the ability of MBAE to enable bottom-up ASLR which, I understand, increases the entropy of ASLR in Windows 7. Windows 8 and later seem to offer greater ASLR entropy than Windows 7. I am therefore wondering if the new protections for Google Chrome introduced in MBAE 1.12.1.136 and 1.12.1.139 automatically take care of this Windows 7 issue and enable bottom-up ASLR for chrome.exe. Does the enforcement of this particular mitigation using MBAE require a dll injection into chrome.exe? If not then why cannot the MBAE user configure MBAE to do this? For all I know, Google Chrome might itself enforce bottom-up ASLR but doubt it because MBAE previously provided for it in Advanced Settings.
  15. hake

    MBAE 1.12.1.136 Experimental

    MBAE 1.12.1.137 is working well. The performance dip in Google Chrome on my slow hardware was due to too many browser extensions which have been pruned down to the essential ones. I am now very satisfied and look forward to further developments. It would be nice to see evidence in the log that Google Chrome is being protected, even if the details are not yet available to the user.
×

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.