ActiveX controls pose a dilemma for IT administrators. While they provide robust capabilities for line-of-business web applications, their mere existence increases the security footprint of applications and can leave systems extremely vulnerable to attack. The latest example of this is Oracle’s Java 7 (1.7.x) series of plugins. A 0-day flaw in this class of plugins has opened up machines to potential exploit (and, in this case, it affects other browsers in addition to Internet Explorer).
The solution to this problem is simple: don’t install binary browser plugins (a la ActiveX controls) onto client machines. No ActiveX controls means no increased footprint, leaving the browser and its built-in functionality as the mainline vector into the machine (aside from other applications). Unfortunately, that doesn’t really work for companies dependent on controls for their day-to-day workflows.
Prior posts have addressed using Browsium Ion to override individual files and registry entries within a single browser session. Custom registry and file system entries can be added to an Ion Profile. Those entries override “real” entries in the Windows registry and file system so these custom registry and file entries are accessed by a web page or control running within an Ion Profile during runtime rather than using the default system values.
Custom registry and file system entries can be used to create zero- and limited-footprint installs of controls. This means that you can install an ActiveX control on a system without actually installing it. You can “install” a control by adding its registry settings and files in a Profile. This Profile will effectively emulate the control installation by overriding file and registry accesses to such a control when the Profile’s process is loaded. When a webpage matching an Ion Rule opens a Profile with the required control “installed,” the control will run as if it was truly present on the system. When a webpage loads that does not match a Rule, the webpage will never be able to load the requested control because it is not actually present on the system.
Zero-footprint installs (ZFIs) allow users to access applications (or, in this case, ActiveX controls) without that application or control being installed on a system. Virtualization solutions typically allow for the packaging of large applications into a file that is passed onto a client and run in a specific context. Ion not only allows for ZFIs but offers an innovative, granular approach to them, allowing you to target ZFIs to specific tabs and webpages using Ion’s Rule-based approach.
To use ZFIs, administrators can gather the files and registry settings needed for a control to run, place them in a location that is accessible over a network (or push them down to a local machine), add them to an Ion Profile, and push that Profile to clients.
An administrator can define an Ion Profile such that the Profile contains all the files and registry settings of a specific ActiveX control. For instance, you can enumerate all the files and registry settings required by Java 1.4.2 update 19, add them into the Custom Files and Custom Registry portions of a Profile, save that Profile, and create a Rule to that Profile for only that specific instance. When that Profile is saved to a system, the Profile’s process starts and loads all the necessary Java 1.4.2 update 19 files into memory. Any webpage loaded using that Profile will be able to use that version of Java because, from the point-of-view of that page, Java is installed on the system. You can find a video example of running multiple versions of Java side-by-side on a single PC on our demos & resources page.
In the case of both Browsium Ion and virtualization solutions, the contents of the package (the payload, consisting of files and registry entries) are pushed to machines. In both cases they are not “installed,” meaning the applications and controls are not registered with the operating system nor are they placed in “well-known” locations. This restrictions means, for instance, that an ActiveX control is “unknown” to a malicious script on a page because that control cannot be instantiated through its GUID or ProgID.
The ZFI approach in Browsium Ion differs from ZFI in virtualization products in that usage of a ZFI can be controlled on a granular level. In virtualization products, ZFI affects the whole process being virtualized; this means that if you enable a specific Java version for a virtualized instance of Internet Explorer, it affects all the web applications and tabs loaded in that instance. With Browsium Ion, you can create rule sets to restrict where a ZFI will be loaded down to an individual web application or set of applications. Such a restriction prevents less-secure controls from bleeding over into applications that weren’t intended to use such controls.
Limited-footprint installs (LFIs) are similar to ZFIs in that both store applications and controls for a limited time in memory. LFIs differ in that they only perform this action for important, “well-known” parts of a payload.
Applications and controls can be broken up into two distinct parts: well-known application files and data, and supporting application files and data. Well-known files and data are the core portions of an application or control: DLLs or EXEs residing in well-known file locations (e.g., those locations present in the environment PATH variables, startup locations, etc.) and well-known registry locations (e.g., COM registration points in the Classes key of HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, path points in Windows startup locations, MIME type references, etc.). Supporting application files and data are “everything else,” resources that the core functionality of an application or control need to run that cannot be instantiated on their own.
Limited-footprint installs can be achieved in Browsium Ion in the same way that zero-footprint installs can—through the Custom Files and Custom Registry interfaces in the Browsium Ion Manager. An administrator can gather the necessary files and registry settings, add them to a Browsium Ion Profile, and deploy that Profile. In this specific case, only the well-known data is added to a Profile, and the supporting data is deployed to machines and laid out in the normal file and registry locations that it would have been if the application or control was installed on the machine in a traditional sense.
When LFIs are defined and run within an Ion Profile, the well-known portions of the application files and data are loaded into a Browsium Ion process during runtime. When these settings are loaded, the modules in the Ion process load the supporting files and data as they would normally from the file system.
LFIs have a significant advantage over ZFIs when it comes to load time of an Ion process. Since LFIs are a subset of all the files and registry settings in a payload, a smaller amount of data is placed into memory during process start. The key to LFIs though is getting it right—an administrator needs to perform due diligence to separate out the well-known versus supporting files and data.
Like ZFIs, LFIs in Browsium Ion can be controlled at the per-tab, per-web page level, providing a more granular experience over similar features offered by virtualization solutions. LFIs can also be used to quickly mitigate new and fast-moving threats like the latest Java 1.7 0-day. Using the LFI approach, you can simply remove the Java 1.7 registration entries from the registry, remove the core Java DLLs from Windows, and turn them into Custom Files and Custom Registry entries in a Profile. Browsium Ion can significantly reduce your security footprint by only loading Java 1.7 (or any at-risk control) on the web pages that you specify.
The concept around implementing ZFIs and LFIs is relatively simple: list the files and registry entries you want to use, add those to an Ion Profile, and deploy. The hard part is the analysis – gathering all the files and registry entries that an application needs to run and, in the case of LFIs, breaking down well-known files and data versus supporting files and data.
Controls and applications with smaller-sized payloads (in the tens of files and registry settings) are best-suited for ZFI implementations. A relatively small number of Custom File and Custom Registry settings will not impact startup times of an Ion process. The Microsoft JVM and DHTML Editor Controls are good examples of ActiveX implementations that could be fully implemented in an Ion profile without causing significant system delay when loading such a profile.
Java is a good example of a control that is better suited for LFI than ZFI. A typical Java install has hundreds of files and registry settings that are required for it to run properly on a system. Adding all these files and settings into an Ion profile would result in low startup times. There are a handful of well-known Java registry entries (the COM registration keys, the HKLM\Software\JavaSoft keys, etc.) and well-known files (the jpi2exp.dll file, the Java SSV loader, the deployment.properties file, etc.) that need to be set as Custom Files and Custom Registry Entries, however the rest can be deployed to systems and installed without applications and webpages ever “seeing” that Java is actually installed. Since the well-known files are only present in Ion processes, the only webpages that can load Java are those loaded within an Ion process and using an Ion profile defining those well-known files and registry entries.
Browsium does not provide software to enumerate all the files and registry entries that an application uses. However, there are a number of free and low-cost solutions to do so. Internally, we use Total Uninstall to enumerate the installed files and registry entries of an installation. Packaging tools for virtualization solutions can also be used to achieve the same result.
Browsium Ion implements ZFI and LFI in a way that gives you granular management of when and where ActiveX controls can be run. When important security flaws are exposed and your organization is at risk, you can use these features to quickly protect against security threats and restrict the loading of vulnerable controls to only the most important line-of-business pages.
If you’d like to give this a try, contact us and we’ll work with you to evaluate Ion in your organization. If you are already a customer, please try this approach out in your own test environments. If you have any questions, email our support team at [email protected].
Cheers,
Matt Crowley
