On Friday of last week HP made available full details of research carried out by 3 security researchers who found new methods of bypassing defences added to Internet Explorer (IE). These are the same researchers that I mentioned in an earlier post. While Microsoft used this research to improve the security of Internet Explorer they only did so for the 64 bit version Internet Explorer. The 32 bit version remains vulnerable to the techniques outlined in this research.
In a blog post HP provided the reasons why Microsoft would not patch the 32 bit version of Internet Explorer. I have summarized these reasons below:
- 64 bit versions of IE benefit the most from ASLR
While this fact is not in doubt, the 32 bit version of IE is still very widely used as I mentioned in a previous blog post. There is a possibility that the amount of development and testing needed to resolve these flaws in the 32 bit version may be much larger than the benefit they would provide. Use-After-Free flaws are usually given Important or Critical severity ratings since such flaws generally require little to no user intervention for them to take place. If zero day exploits begin to appear, Microsoft may be forced to reverse this decision.
- MemoryProtect has led to a significant decrease of IE case submissions
Presumably case submissions refers to the number of Use-After-Free and other memory corruption flaws being submitted to Microsoft for analysis. Again while I acknowledge this is the case and that no mitigation/defence is perfect; when known security issues are presented to you and can impact a very large number of users you should still try to either reduce the risk further or (if possible) eliminate these issues completely (by in this instance, patching them).
Aside: What is a Use-After-Free vulnerability?
As a web browser downloads and processes the web page that you have requested to view, it stores the results in memory (the Random Access Memory (RAM) of your PC). When you close a tab of your browser, your browser will mark the memory in which that webpage was stored as free (for further use at a later time).
However where the browser marks memory that it has finished using as free but then tries to use it again (either unintentionally via a software bug resulting from human error or maliciously via a piece of malware), malicious code can be placed by an attacker within that section of memory marked as free and when the browser accesses that section again, it can execute that code. Such exploits are discussed in more detail in this Cisco blog post.
Further alternative definitions of a use-after-free issue are also available:
Red Hat (in reference to a recent Linux kernel vulnerability)
Perception Point: exploiting a use-after-free on a Linux system
Microsoft (also details use-after-free mitigations built into Microsoft Edge and Internet Explorer).
Some may feel that I have been unduly harsh on Microsoft in the above comments. I do believe that not all of the information as to why these issues are not going to be patched has been provided. I also believe that Microsoft should at least consider implementing the suggestions within pages 19 to 21 of this white paper to make exploitation of these issues more difficult.
One interesting point that is raised in the HP blog post is the following “Since Microsoft feels these issues do not impact a default configuration of IE (thus affecting a large number of customers).” That comment makes more sense (especially if such non-default configurations are not recommended) but no detail is provided as to what settings make IE vulnerable to these flaws (and thus you can’t make the necessary changes to your configuration to mitigate these flaws). It will be interesting if any more information can be obtained concerning this non-default configuration.
What Can I Do To Defend Myself From These Unpatched Issues?
- A suggestion that does not cost any funds and is easy to implement would be to use another web browser (Mozilla Firefox, Apple Safari, Opera and Google Chrome being the most popular choices).
- If you are using a 64 bit version of Windows (you can view this page to check which version you have), use the 64 bit version of IE instead of the 32 bit version. This post explains how while this post also provides steps to enable all IE’s processes to be 64 bit rather 32 bit. If you find an add-on that you use frequently does not work with the 64 bit version of IE, simply reverse the steps in the above tutorials temporarily. Alternatively navigate to the folder: C:\Program Files (x86)\Internet Explorer and double click iexplore.exe to open the 32 bit version of IE.
- Install and enable the default settings of Microsoft EMET. On my personal PCs which use Windows 8.1 64 bit and Windows 7 64 bit I have all mitigations for IE 11 64 bit enabled (please note that I have ActiveX filtering enabled and thus no add-ons are running within IE on my PCs). The same settings should work for IE 32 bit. A list of known EMET application incompatibilities is available here. You can also ask questions within the EMET forum. The following are very useful tutorials on EMET 5 and EMET 4 (still relevant).
- When Windows 10 is released consider using Microsoft Edge since it incorporates additional defences against Use-After-Free flaws and will always be a 64 bit process on a 64 bit version of Windows 10.
The recommendation of using EMET will not only protect against these unpatched flaws but also make exploitation of known flaws much harder. Alternatives to EMET are Malwarebytes Anti-Exploit (free or paid for versions) and HitmanPro.Alert (paid for product).
I hope the above information is useful in defending against these unpatched flaws. When I first read the blog post from HP I initially thought that the 32 bit version of IE was being ignored but the information stating that these issues only affect non-default configurations of 32 bit IE makes these issues much less serious. If any further information on these flaws become available, I will update this blog post.