Recently this blogger had to debug a website problem on a particular combination of Windows and Internet Explorer. Modern-IE website built by MSFT has exactly the solution for this. Part of the massive marketing campaign to stop the long and slow decline in market share against competition from Firefox and Chrome, the site provides a wealth of resources for developers trying to ensure interoperability of their work against IE. Chief among those resources are virtual machines images for different Windows versions preloaded with commonly matched version of the web browser, going all the way back to such archaic combinations as the long-deprecated IE6 running on recently deprecated but-not-quite-abandoned Windows XP. (Lest anyone assume this is a free way to run Windows: the images are evaluation copies set to expire after a couple of weeks, similar to the evaluation VMs targeted at IT professionals.) More importantly, in a departure from MSFT-as-usual approach to assuming that users have bought into the MSFT ecosystem of Windows, Office, Active Directory and all other software, Modern-IE caters to developers using other virtualization platforms and even more surprisingly, alternative operating systems. For example, not only does it offer VM images customized for VMware Player— a competing offering against Hyper-V derived technology built into Windows– but there are images aimed at OS X and Linux users. (Curiously only VirtualBox images are offered for Linux, even though the VMware image would normally work just fine there, unless there is some hardware compatibility problem in the way the guest machine is configured.)
Authentication is hard
Unfortunately while the attempt is laudable, the implementation leaves much room for improvement. In particular, the way these images are packaged coupled with how they are downloaded creates a security vulnerability. Specifically a man-in-the-middle attack that modifies user traffic can replace the legitimate files by a maliciously crafted image and cause users to execute malicious code on their own machine. Of course virtual machine images are “code” in one sense, since they contain an entire operating system and associated applications. But that code is intended to be executed in the so-called “guest” virtual machine, isolated from the host environment by the virtualization boundary. Surprisingly the way Modern-IE packages and downloads VM images can result in code execution on the host machine running the VM, without requiring any vulnerabilities in the hypervisor or other failure of containment.
So what is wrong with the MSFT approach?
- Download links are presented on a page that does not use SSL (Curiously the website does respond over SSL, but only to redirect users back to the unencrypted HTTP version.)
- The only way to check the integrity of downloads are MD5 hashes, also displayed over HTTP.
- VM images are packaged as multi-part RAR archives.
Let’s drill into each of the problems.
Trusted links from untrusted pages
First one has a slight twist. The download links themselves are using SSL but the page containing the links does not. This is sufficient to enable a classical man-in-the-middle attack. An adversary network traffic can substitute different links when the user is retrieving the top-level page. Incidentally the links themselves provide no indication that the content is authentic, pointing to a domain named “az412801.vo.msecnd.net”– totally legitimate? (Also amusingly the download instructions linked from the main page are served over SSL, but use PDF format. Just in case you needed another file-type frequently implicated in code-execution vulnerabilities.)
Integrity-check is security theater
Second one does not work as an integrity check, because the cryptographic hashes are also distributed over an unprotected HTTP connection. If an attacker is in a position to tamper with downloads, they are in just as good a position to tamper with a web-page displaying the expected hash for that download.
By the way that assumes users will go out of their way to check MD5 hashes manually. Given that the site is intended for a technical audience, one can argue this is not too much to ask for, although Windows developers will be slightly more inconvenienced. OS X and Linux have openssl command line pre-installed so they are one command away from hashing the file. Windows does not have a built-in MD5 checker although an unsupported command line tool can be found on MSDN. Not that it matters; none of the setup instructions mention anything about verifying the integrity of downloaded images.
Incidentally the choice of hash function is a throw-back to the 1990s. Following the initial Wang et al collision results against MD5, Windows security division initiated an MD5 deprecation effort around 2005, complete with a dedicated “MD5 program manager” role to oversee that project across different parts of the codebase. Clearly someone did not get the memo. (If MD5 hashes had been served over SSL, they could still have provided a reasonable guarantee. While pairwise collisions are easy to craft for MD5, this scenario requires a second pre-image attack eg crafting a malicious file that has same hash as a predetermined legitimate file, which the attacker has no control over.)
Choice of compression format
These two issues alone would not be as much of a problem if it were not for the third one. After all, plenty of content such as images and videos are downloaded over HTTP everyday without any way to authenticate their integrity. But RAR archives are self-extracting. Decompressing and extracting the VM image involves running the first chunk, which is just an executable binary for the appropriate platform: PE on Windows, ELF on Linux etc. Strictly speaking it is possible to unpack RAR archives without executing it using utilities such as the open-source unarchiver. But the instructions from MSFT are not that cautious: they simply suggest running the SFX file.
(Also worth mentioning: even without the unfortunate choice of RAR, running an arbitrary VM image is dangerous. Most virtualization platforms allow some sharing between host and guest, such as sharing folders on the host operating system with the guest. An attacker can craft a VM image specifying that user home directory will be shared with the guest operating system. That configuration would allow obtaining private user data or getting code-execution on the host by tampering with configuration, since attacker also controls the code executing inside the guest.)
What is a better approach?
- Display the download links from a page that is itself served over SSL. (Failing that, at least use SSL for displaying the cryptographic hashes but then burden is on the user to take extra steps for verifying them.)
- Do not use RAR. It is an odd choice, a proprietary format not introduced by MSFT and still primarily used on Windows. Its main advantage is ability to split compressed archives into multiple pieces. Yet it’s been a long time since anyone had to worry about breaking up large files into smaller chunks to work around the 4GB limitation of FAT32 file systems. For OSX/Linux, both bzip or gzip are usually built-in and can handle large files. Meanwhile plain zip would be supported equally well on all platforms, providing a single cross-platform solution. (RAR packaging is platform specific necessarily, since the first chunk must be a native executable for that platform.)