hake

To Pedro: The zipped log files have been sent to you by PM.

MBAE 1.07.x.xxxx could do with detecting Windows XP in order that the features which are causing it to be unusable with at least some XP installations could be disabled by default (with the option to manually enable them). This would, I hope, allow it to continue to run as sweetly as MBAE 1.06.1.1019 and ensure that it does not disable systems of XP users when they receive the update.

EMET allows enforcement of ASLR for Windows Vista, 7, 8, 8.1 and later. I see no mention of ASLR (I am not referring to bottom-up ASLR) in anything I have read about regarding MBAE so am puzzled as to whether ASLR is actually enforced on many Windows systems. I deploy EMET 5.2 on all Windows 7 and 8.1 systems that I oversee and ASLR is thus enforced through EMET, when the ASLR option is ticked. I am therefore not personally inconvenienced if the lack of enforcement of ASLR causes a successful exploit.

To Pedro: The CMD prompt hangs completely. Eventually it wakes up sufficiently to allow the DOS window X button to be usable. The MBAE 1.07 issue occurs on all my Windows XP PCs. Unfortunately they all lack the Nx bit but only one of them is running BufferShield. I have a friend who is using MBAE with Windows XP but her system supports hardware DEP. I won't be able to try MBAE 1.07 on it until next Sunday.

It's looking like the only way I can continue to use MBAE with XP is to roll back to 1.06.1.1019 and put up with the invitations to upgrade. Both other problem systems all support XP, all lack the Nx bit but do not run BufferShield, basically because BufferShield doesn't seem to like those laptops. The really odd aspect of MBAE 1.07.1.1008 is that DOS bat files hang. There is no obvious answer because MBAE is concerned with applications, not system function. The behaviour of 1.07.1.1008 is excellent on Windows 7 (64-bit) with none of the application hangs which my XP environments suffer.

It seems that MBAE 1.07.x.xxxx creates more sensitivity than previous versions over conflicts between EMET's non-ROP settings and it's own equivalents. My rule with EMET is not to set EAF and the ROP options when an application is listed in both EMET and MBAE. However, with my DEP agnostic PC I am relying on EMET to look after non-ROP protections available in MBAE's Application hardening tab in Advanced settings so as to avoid applications from freezing. With my Windows 7 64-bit system though, I can set the non-ROP options in EMET (except for EAF) and allow the MBAE default settings in it's Application hardening tab in Advanced settings and applications just run. Such are the behaviour differences between the different Windows systems. Regarding DEP, the realisation of the conflict involving BufferShield has been helpful in sundry matters including a curious problem with rendering fonts on the http://www.theguardian.com/uk newspaper web site in Opera 12 on my ancient Windows XP non Nx-bit system. It also resolved a small issue where the acs.exe process of Outpost Security Suite Pro 9.1 was using a consistent 2% of CPU time after Opera 12 had been in use for a while, even after Opera 12 was terminated. This has now ceased.

I see no options for ASLR enforcement in Advanced settings. Is this compulsorily enforced by default for Windows Vista and later?

Pedro, I have PMed you with a possible explanation of the issue I am having with MBAE 1.07.x.xxxx. In addition to what I wrote, I have now also unchecked DEP Bypass protection in the OS Bypass Protection tab of Advanced settings. Please let me know what you think.

The protection events log seems very slow to update. It also seems to me that when the protection events log is enabled, some applications have trouble running. This particularly applies to Office 2003 applications and also Adobe Acrobat Pro 6. I have switched off this feature and things work better without it. Uh oh! WINWORD.exe won't start but it still appears in Task Manager's process list. I try WORD 2003 again and it does start. Now two WINWORD.exe entries in the process list. I like being able to edit the custom protection shields, if only to reassure myself that I have given the correct executable name and selected the correct application profile. :-)

To Pedro: I have PMed the logs as requested. The 'bad' behaviour occurs when all the advanced options in MBAE 1.07.1.1007 are checked. For example, Acrobat Pro 6 won't run when anti-heap spraying or bottom-up ASLR are enforced. I seem to remember you asking for reports on the effects of checking all the options. With MBAE 1.07.1.1007 it causes problems whereas MBAE 1.06.1.1019 behaves well with all advanced options checked. Once the options have been misused and an application, e.g. Acrobat 6, has been crippled, the only way to put things right seems to be to uninstall and then reinstall MBA 1.07.1.1007, ensure that the options defaults are restored and the applications should then be found to work. Mozilla Thunderbird settings are entered after being shown the warning 'Here be dragons'. This now seems appropriate for Advanced options in MBAE too. Bearing in mind my experiences described above, I respectfully suggest that you consider ensuring that when updating previous MBAE versions to MBAE 1.07.x.xxxx, that the updating process ensures that the Advanced settings are forced to the defaults.

Windows XP SP3 32-bit with Agnitum Outpost Security Suite Pro 9.1 MBAE 1.07.1.1007 seems not to be behaving itself with Outpost Security Suite. This is a hair tearing out thing. Everything worked OK until I ran Word 2003 and then the system seemed to have a glitch. Some low level issue here I think. A DOS bat file also hanged. Reinstating MBAE 1.06.1019 eliminated the issue. This is the first time that I have found an experimental release has not behaved reasonably well. I cannot get a handle on the circumstances which are causing it.

My understanding is that AntiExploit intervenes in the process of initiating the installation of malware, for example preventing the capabilities in a web browser from being misused in order to cause malware to start running. That is where the exploit is at work. Please correct me if I am mistaken.

I have been reading http://www.zdnet.com/article/pwn2own-2015-the-year-every-browser-went-down/ and it set me wondering if the hackers would have scooped up their handsome prizes if MBAE had been installed on the test systems.

Why do I prefer to use both EMET and MBAE? EMET is there as a back-stop contingency in case MBAE Premium subscription renewal is unsuccessful or there is a hiccup in that process. I assume that MBAE's fallback on failure to renew a subscription is free protection for browsers and Java. I have not seen that MBAE is described as providing equivalents of EMET's SEHOP and NullPage mitigations. If an application is protected by MBAE then I only enable DEP, SEHOP, NullPage, HeapSpray and Bottom-Up virtual memory randomisation in EMET4.1u1 and additionally EAF+ and Mandatory ASLR in EMET 5.2. EAF and all ROP mitigations in EMET must be disabled for MBAE protected applications. So far, observation of these conditions seems to allow harmonious co-existence between MBAE and EMET.

Sorry. I should have known better. Correction to A side issue: Clicking on the MBAE desktop icon the first time after startup always causes the MBAE window to open but if the settings dialog box is opened then subsequent clicking of the desktop icon causes the settings dialog box to open first. However, clicking on the taskbar icon always causes the MBAE window to open first.

With XP, at least, I have had problems when reverting to the previous production release. Installing MBAE 1.5.1.1016 over the new RC resulted in being told to restart the system. On electing to restart, the display screen went haywire and the system hanged. After restarting using the power switch, I uninstalled MBAE 1.5.1.1016, restarted the system (which shut down very slowly), reinstalled the RC then uninstalled it (I guess to remove stuff which reinstalling MBAE 1.5.1.1016 might not have removed), restarted system (it hanged and needed power cycling again) and installed MBAE 1.5.1.1016 which then worked properly. BTW, I found that RC 1.06.1.1010 worked OK with Word 97 and Excel 97. The system is a 2001 Acer TravelMate 220 laptop running XP. This had previously been of good character but something in the RC or the uninstalling thereof upset it. Anyway, it's now running OK again with MBAE 1.5.1.1016 and seems no worse for its experience. A side issue: Clicking on the desktop icon the first time after startup causes the MBAE window to open but the second time and thereafter it causes the settings dialog box to appear, the closing of which then opens the MBAE window. However, clicking on the taskbar icon always causes the MBAE window to open.

I have installed Release Candidate build 1.06.1.1010. The Advanced Settings are most interesting. I see that mitigations analogous to EMET's mitigations are indicated but that MBAE's ROP mitigations in particular are employed where EMET's ROP mitigations would cause EMET to terminate the process if also mitigated by MBAE. Do MBAE's mitigations take precedence over EMET's? Initial impressions are that Release Candidate build 1.06.1.1010 seems to work fine. WIth Windows XP it is running with EMET 4.1u1 and with Windows 7 (64bit) it is running with EMET 5.2. I do have reservations about tooltips where users are non-tech, especially if tooltips are persistent. For me a default 'off' would be preferable for production releases of MBAE.

I have discovered another possible cause of this. A few weeks ago, I had a brief dalliance with OnlineArmor. Aftet Agnitum had sorted an Outpost Security Suite problem, I reverted to Outpost. This entailed uninstalling OnlineArmor which I did and entrusted the tidying up of registry entries and driver files that I assumed were taken care of after the restart initiated by the uninstall process. Blissfully unaware that this tidying had not actually taken place, I continued to use XP and experienced occasional spontaneous restarts. This bothered me as a potential sign that my motherboard might be showing signs of age. Sandboxie finally gave me the clue as it was stating that it was detecting OnlineArmor for its software compatibilty adjustments. I found that installing OnlineArmor, refusing it permission to run and instead immediately uninstalling it finally exorcised the problem remnants of OnlineArmor. Sandboxie is now happy and my system no longer spontaneously restarts. I have not yet had a chance to recreate the scenario for the MBAE/AVG/Outpost issue but circumstantial evidence suggests that the unwanted drivers (the only files in folder C:\Windows\System32\driver called oa*.sys) were active and there were undeleteable registry entries which referenced them. I will post again on confirming my hunch.

I have also observed this problem occurring with BitDefender Free AV in combination with either PrivateFirewall or Outpost Firewall Pro. With either of these in use without the other MBAE functions properly but when the two are both installed then MBAE dies. On the other hand, the combination of Avast with either of PrivateFirewall or Outpost Firewall Pro does not prevent MBAE from functioning. Do BitDefender and AVG AV products have some characteristic in common which Avast lacks?

I have identified the cause of the distorted fonts. It was KB3013455. This KB also caused problems for Windows Vista and Windows 2008 Server so the XP updates 'fix' was not to blame. I have now caught up with the Patch Tuesday updates for both February and March 2015 without incident, the systems behaving properly on restart. I take the hint about doing a trial run before committing to the updates. Judging from the recent Windows 7 reboot loop after an update, legit MS Windows updates are also an act of faith by the user.

Thank you Pedro. That is very valuable. The Adobe font driver vulnerability is said to be a 'nasty' one. In addtion to MS Office applications can it also affect web browsing? I can source a POSReady update (KB3032323) to immunise Windows XP from the Adobe font problem but would prefer not to since there was an update in February's Patch Tuesday which caused MS Office fonts to be malformed in XP (I'm still unaware which KB was responsible). I am now very circumspect with MS updates for POSReady.

Microsoft Security Bulletin MS15-021 - Critical Vulnerabilities in Adobe Font Driver Could Allow Remote Code Execution (3032323). Can MBAE protect from this?

Concerning MS15-024 of March 2015 Patch Tuesday updates, Microsoft states "The vulnerability could allow information disclosure if an attacker convinces a user to visit a website that contains specially crafted PNG images." Is this the kind of thing that MBAE is likely to be able to mitigate?

That's good news. It shows that there is no inherent problem. I would imagine that it is a problem particular to this incarnation of Windows XP. I used no special configuration of Outpost Firewall Pro other than to allow it to adjust to AVG for compatibility. There are other AV products I could try but as long as Agnitum Outpost Security Suite continues to support Windows XP, I do not need to resort to using the Outpost firewall product which does not absolutely depend on data updates in order to function. That is why I was trying out AVG. The problem also occurred with MBAE 1.04 by the way. I have a copy of the system with AVG and Outpost Firewall on a removable hard drive so can give the next MBAE version a go when it is released.

I found that unless Outpost Firewall Pro is allowed to make adjustments for incompatibilties with AVG at installation, the two seem to fight like crabs in a jar. After installing Outpost, I restored a config file for another installation of Outpost Firewall. This probably would not have incorporated the compatibility adjustments for AVG. The result was that my system was susceptible to random spontaneous restarts. Stability was recovered when I reinstalled Outpost properly and did not introduce another config file. I mention this in case it reveals something useful. The answer of course is to use Outpost Security Suite which I normally do. This, as btmp has confirmed, works perfectly with MBAE.