Exploring the x64-treme heights of the Internet

Having released two major Windows versions for the x64 architecture (also known as ‘AMD64’), Microsoft has opened the door to inexpensive 64-bit computing for just about everybody. At the 2005 Virus Bulletin Conference I presented a paper on the x64 architecture, detailing how known 32-bit viruses and rootkits interact with it.

There were a number of questions from the audience at the end of the presentation, but the most interesting one was a question posed by a researcher from Symantec’s European AntiVirus Research Centre. It related to Internet Explorer in Windows x64 and how ActiveX objects and BHO (Browser Helper Objects) – which until now have been exclusively 32-bit – work (or don’t work) in the Windows x64 environment. The significance of this, of course, is that there is a great plethora of spyware and adware which installs from the Internet via IE vulnerabilities, through the use of ActiveX technology or Java applications.

This article is written in response to that question.

Meet Internet Explorer x64

Since all the system applications in Windows x64 are 64-bit PE files, one would assume that Internet Explorer has also been compiled as a 64-bit native application. The assumption is correct – a 64-bit Internet Explorer (version 6.0.3790) is built into the most recent Windows XP release for the x64 platform. Its ‘About’ dialog is shown in Figure 1.

Fig. 1: Internet Explorer 64-bit edition

However, what may not be so obvious is that, alongside the 64-bit Internet Explorer there is also a 32-bit version of IE available from the Start menu (see Figure 2). When run, the 32-bit Internet Explorer looks identical to its 64-bit twin, but a quick check in the Task Manager shows that it is indeed a 32-bit process.

Fig. 2: A 32-bit edition of the same product is available from the Start menu

So it seems that the Windows developers have decided to offer the user the choice of which version of Internet Explorer to use. Although this may sound a little strange, there is a very good reason: compatibility.

In Windows x64, the 64-bit applications can make use of IPC to call older 32-bit code, just like 32-bit applications can call 16-bit DLLs in Win32 through the use of thunking. This means that, at least in theory, any 64-bit application could be made to use a 32-bit DLL. However, calling 32-bit code from a 64-bit application does not come without drawbacks, speed and security being the main concerns.

Notwithstanding these concerns, in theory, the 64-bit Internet Explorer could have made use of 32-bit ActiveX objects and plug-ins. So why did Microsoft choose to ship a 32-bit version of Internet Explorer with Windows XP x64?

One simple explanation is that to make 32-bit ActiveX objects work from the 64-bit IE, IE would have to open a 32-bit VM, load the 32-bit COM object in there and communicate with it. The technical effort required would not be trivial, but for a company of Microsoft’s size, this should not be a serious problem.

Another possibility is that having 32-bit ActiveX objects enabled in the 64-bit Internet Explorer opens the door to a large set of security threats that have been plaguing the Internet for years. It also requires the coding of a special application gateway: a 64-bit wrapper for ActiveX objects that lessens the separation between the 64-bit and 32-bit worlds in Windows x64. This is important because, for example, 64-bit and 32-bit applications ‘see’ different versions of the registry and can of course have different types of configuration settings and therefore behave differently.

Whichever of the explanations (or other unexplored possibilities) is correct, Windows x64 includes two versions of IE. Let’s see how they handle ActiveX controls.

The ActiveX technology

ActiveX is a generic name for a set of technologies which have been developed with the purpose of sharing information between applications. ActiveX is related to COM and OLE, but most of the time ActiveX is used to denote ‘ActiveX controls’. In this case it is the technology designed to be called from a web browser.

Many years ago, when ActiveX was made available in Internet Explorer, it was considered a direct competitor for Java. However, Microsoft’s IE was the only browser on the market that supported it. One of the main arguments against ActiveX was that it was based on x86 executable code, making it very hard to operate on other CPUs such as PowerPCs or Sparcs. As a result, companies writing true multiplatform applications would be limited to running them through Microsoft’s browser, and only on Intel-compatible PCs.

In fact, Microsoft even shot itself in the foot with ActiveX, as running Internet Explorer doesn’t necessarily mean that you have an environment which supports ActiveX! For instance, the MacOS Internet Explorer (most recent version: 5.2.3) is unable to load and run ActiveX controls. So, while Java meant that you have a variety of systems and hardware architectures on which to run your applications, ActiveX meant that your code would run on Intel x86 32-bit CPUs under Windows. With the arrival of Windows x64, ActiveX developers have one more platform to worry about – 64-bit Internet Explorer ActiveX controls.

Peculiarities of 32-bit and 64-bit Internet Explorer in Windows x64

The 64-bit Internet Explorer from Windows x64 is located in the ‘Program Files’ folder, separated from the 32-bit version. It supports plug-ins and, as one might have expected, it is able to load and run 64-bit ActiveX controls.
However, it is interesting to note that Windows x64 defaults to the 32-bit Internet Explorer in most cases. The 32-bit IE is called when clicking the IE shortcut on the Taskbar, from the ‘Windows Update’ Start Menu item and from the Desktop IE Shortcut. Yet, when an Internet URL is requested from the Windows Explorer – which is a 64-bit application itself – the 64-bit IE is used.

The behaviour of ‘Windows Update’ is also interesting under Windows x64. As mentioned, the Start Menu item for ‘Windows Update’ launches the 32-bit Internet Explorer, which loads all the update controls – which are 32-bit applications themselves. However, if you open the Windows Update website in the 64-bit Internet Explorer, you get the message shown in Figure 3.

Fig. 3. Opening the Windows Update in 64-bit Internet Explorer

Unfortunately, I do not have an Itanium IA64 machine handy to test whether the Windows Update has a native IA64 ActiveX control, or whether the update is run as emulated 32-bit code, but this is definitely worth trying.

Continuing with the peculiarities of the 32-bit and 64-bit versions of IE from Windows x64, it is worth noting that they share a couple of settings, such as using the same Temporary Internet Files folder (which defaults to ‘Documents and Settings%Username%Local SettingsTemporary Internet Files’), the same History folder and the same Favorites folder.

In version IE 6 SP2, Microsoft introduced a very useful feature to manage the IE Add-ons. It can be found in the Tools menu: ‘Tools->Manage Add-ons’. The Add-ons Manager can be used to disable or re-enable ActiveX controls or Browser Extensions, but unfortunately it can’t be used to uninstall any of these. This gives the user a better idea of the extensions currently used by IE, as well as providing a moderate degree of control over them.

64-bit IE Plug-ins

Neither of the versions of IE from Windows x64 supports Java by default, so one has to download and install Java support separately. Of course, there is a 32-bit JRE in the most recent release from Sun (J2SE Runtime Environment 5.0 Update 5), but there is no Windows AMD64 support listed on Sun’s website. There is an AMD64 version of the J2SE Runtime Environment 5.0 in Update 4, which can be obtained from Sun. However, it doesn’t seem to work in Windows XP x64. It installs without error messages, but IE does not include it in the list of Add-ons loaded, and Java applets do not work when called from a web page.

Additionally, there is no Windows x64 Flash Player from Macromedia, no Acrobat Reader x64 from Adobe and no direct in-browser QuickTime support from Apple. In fact, at the time of writing this article, I have been unable to find any 64-bit IE plug-in, or third-party 64-bit ActiveX control.

This means that the 64-bit Internet Explorer experience does not (yet) support Java applets, Shockwave or PDFs, which in practice limits its usefulness to the point where many users will have no reason to use it at all. Except of course, if no support for the above-mentioned types of content is what they want in the first place.

Malware attacks

As a result of the inability of the 64-bit IE to call 32-bit x86 code, current 32-bit malware attacks are greatly limited. In practice, none of the current methods used to deliver malware through web pages work, except maybe for direct download and execution by the user.

Not surprisingly, the same cannot be said for the 32-bit Internet Explorer from Windows x64. I have tested a range of malware that installs itself from various web pages, including but not limited to (all KAV names):

• Trojan-Downloader.Win32.IstBar.jm
• Trojan-Downloader.Win32.IstBar.kq
• Trojan-Downloader.Win32.IstBar.ij
• Trojan-Downloader.Win32.Dyfuca.ei

These are all delivered from web pages through the use of various IE exploits (which are already patched in the IE6 for Windows XP x64 so they don’t work) and through the use of ActiveX controls. Some of these use Win32 kernel mode rootkits to hide themselves (which do not work in Windowsx64) and some of them rely on user-mode rootkits, which are effective against other Win32 applications in Windows XP x64, but not against 64-bit applications.

The bad news is that not only they do infect the system successfully (although they all require the user’s confirmation to install), but they also operate without glitches under WOW64. They survive reboot even if the BHOs are disabled from IE prior to restarting, and they are not easy to get rid of without a full-blown 64-bit anti-virus scanner.

In fact, without a 64-bit anti-virus scanner (and unfortunately, the offerings are still very limited in this area) getting rid of 32-bit malware on Windows x64 is not a straightforward task for the inexperienced user. Of course, an experienced user could always kill all 32-bit processes in Task Manager, and then use a plain 32-bit scanner to disinfect or delete all the infected files, but the separation between 32-bit processes in Windows x64 makes it quite difficult for a 32-bit AV scanner to remove some of the above-mentioned malware while they are active.

Conclusions

With Windows x64, Microsoft seems finally to have shipped a version of IE which is pretty much safe from most of today’s IE-oriented malware attacks – I’m talking about the 64-bit IE, of course. The bad news is that this isn’t thanks to a breakthrough in security on Microsoft’s part, but comes as a side effect of the total absence of support for Java, 32-bit ActiveX controls, Shockwave content and PDFs. And, thanks to this lack of support, most users will simply use the 32-bit Internet Explorer, which as we’ve seen, is just as malware-friendly as any other version running on Windows XP 32-bit. However, with an up-to-date 64-bit AV scanner with the O/A component activated, most users should have no problem dealing with 32-bit malware – in fact, 32-bit malware should be easier to deal with because of the good separation between the 64-bit and 32-bit worlds in Windows x64. In this case, users of Windows x64 will have fewer problems with malware than their 32-bit counterparts. That is until 64-bit malware starts to become popular, of course.

Bibliography

This article was originally published in Virus Bulletin, December 2005.

1. Costin Raiu, “Enhanced” virus protection, Proceedings of the Virus Bulletin International Conference 2005, ññ. 131–138.
2. Microsoft: List of limitations in 64-Bit Windows
3. Microsoft: Differences between the 32-bit and 64-bit versions of Internet Explorer that are included in the x64-based versions of Windows Server 2003 and in Windows XP Professional x64 Edition