hake

Mozilla states that Firefox ESR will not block dll injections until 2020.

https://borncity.com/win/2019/03/07/google-chrome-72-0-3626-121-closes-critical-vulnerability/#more-8824 Arrogant Google locks out MBAE and yet still perpetrates its own vulnerabilities. If ever there was evidence that a devil's advocate is needed for Chrome, this is it. Google cannot be trusted to ensure its unaided protection of the security of its own users. Google aids and abets hackers to do their insidious work silently and with impunity. Of course we cannot know if MBAE would have detected the exploits because Google excluded it.

Previous aversion to https://www.dailymail.co.uk clickbait/scams (alleged) still present.

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.

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?

@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.

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.

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.

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.

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?

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

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?

??? The problem behaviour has ceased since the December Patch Tuesday updates were installed.

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.

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?

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.

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.

I am using MBAE 1.12.1.137 and it actually seems to be on a par with MBAE 1.12.1.109. Nothing remarkable of note to observe right now. It works and you can't say fairer than that.

I have tried MBAE 1.12.1.136 on Windows 7 (64bit) and find that it seems to have imposed a performance penalty with Google Chrome (latest 32bit version). Admittedly my hardware is 12 years old (Intel Pentium 4 twin core 3.2GHz processor) but using that slower hardware also emphasises the effects of performance hits. Reverting to MBAE 1.12.1.109 restores performance to what was previously normal. Google Chrome has not yet given MBAE 1.12.1.109 the sack. When that happens, I shall probably give Google Chrome the sack.

Thank you Arthi.

@Arthi: Can you please confirm that your words "we have implemented an alternate approach to offer protection to Chrome and Edge users without DLL injection" mean that MBAE 1.12.1.136 includes this?

Protection is decribed as "New Updated Protection for Chrome and Edge Browsers ". I guess that this does not apply to chrome.exe of Google Chrome.

If Google sweeps away the irritant of the third party anti-malware specialists and appoints its own personnel to be sole guards of its web browser, who will guard the guards? What pressures of expediency will in the future suppress due diligence among its own developers? This sort of change comes from higher up in a parent organisation. How will users know in future if Google Chrome is vulnerable to exploits when the alarm is silenced? If Google was infallible then it would not matter. The black hats must be rubbing their hands in glee.

It appears that there is no obvious way to communicate user unhappiness to Google. Google seems to wish to bury its head in the sand. This is not good for Google or user.

I get this too. https://www.dailymail.co.uk is not white-listed by Ghostery. An odd thing is that I receive this presumably false positive when browsing with Opera 56 but not with Google Chrome 69 (I am running MBAE 1.12.1.109). Browser and content settings for each are as near the same as I can make them.