Future Research

With the technique identified for being able to control the top-level UEF by taking advantage of asymmetric deregistration, future research can begin to identify better ways in which to accomplish this. For instance, rather than relying on child windows in Internet Explorer, there may be another vector through which ole32!CoFreeUnusuedLibrariesEx can be called to cause the asymmetric deregistration to occur^7.1. There may also be better and more refined techniques that can be used to more accurately spray the heap in order to place arbitrary code at the location that a defunct top-level UEF resided at.

Aside from improving the technique itself, it is also prudent to consider other software applications this could be affected by this. In most cases, this technique will not be feasible due to an attacker's inability to control the loading and unloading of DLLs. However, should a mechanism for accomplishing this be exposed, it may indeed be possible to take advantage of this.

One such target software application that the authors find most intriguing would be IIS. If it were possible for a remote attacker to cause DLLs that use UEFs to be loaded and unloaded in a particular order, such as by accessing websites that load COM objects, then it may be possible for an attacker to leverage this vector on a remote webserver. At the time of this writing, the only approach that the authors are aware of that could permit this are remote debugging features present in ASP.NET that allow for the instantiation of COM objects that are placed in a specific allow list. This isn't a very common configuration, and is also limited by which COM objects can be instantiated, thus making it not particularly feasible. However, it is thought that other, more feasible techniques may exist to accomplish this.

Aside from IIS, the authors are also of the opinion that this attack vector could be applied to many of the Microsoft Office applications, such as Excel and Word. These suites are thought to be vulnerable due to the fact that they permit the instantiation and embedding of arbitrary COM objects in the document files. If it were possible to come up with a way to control the loading and unloading of DLLs through these instantiations, it may be possible to take advantage of the flaw outlined in this paper. One particular way in which this may be possible is through the use of macros, but this has a lesser severity because it would require some form of user interaction to permit the execution of macros.

Another interesting application that may be susceptible to this attack is Microsoft SQL server. Due to the fact that SQL server has features that permit the loading and unloading of DLLs[2], it may be possible to leverage a SQL injection attack in a way that makes it possible to gain control of the top-level UEF by causing certain DLLs to be loaded and unloaded^7.2. Once that occurs, a large query with predictable results could be used as a mechanism to spray the heap. This type of attack could even be accomplished through something as innocuous as a website that is merely backed against the SQL server. Remember, attack vectors aren't always direct.