There’s an odd bit of behavior that some Windows systems will exhibit when certain kinds of installers are launched, automatically elevating the privileges of the installer process to system-level privileges. In theory, the issue shouldn’t be exploitable because at one point in the process the system will generate an MD5 hash of a DLL that’s to be loaded, and unless the attacker can replace that DLL with a malicious one that sports the same hash, an attack is impossible. But those constraints may not hold for all attackers, a researcher says.
The weirdness in Windows 7 and Windows Server 2008 was identified by Cesar Cerrudo of IOActive, and he spent some time looking into exactly what causes it and whether he’d be able to exploit the condition. The issue arises when an installer for a program that is already installed on a given machine is executed. When one of those installers is run, it will automatically elevate the privileges of the current installer process to the System level. That would theoretically give an attacker a local elevation of privilege bug, granting him system privileges.
“However, an interesting issue arises during the installation process when running this kind of installer: a temporary file is created in C:UsersusernameAppDataLocalTemp, which is the temporary folder for the current user. The created file is named Hx????.tmp (where ???? seem to be random hex numbers), and it seems to be a COM DLL from Microsoft Help Data Services Module, in which its original name is HXDS.dll. This DLL is later loaded by msiexec.exe process running under the System account that is launched by the Windows installer service during the installation process,” Cerrudo wrote in a blog post explaining the issue.
“When the DLL file is loaded, the code in the DLL file runs as the System user with full privileges. At first sight this seems to be an elevation of privileges vulnerability since the folder where the DLL file is created is controlled by the current user, and the DLL is then loaded and run under the System account, meaning any user could run code as the System user by replacing the DLL file with a specially-crafted one before the DLL is loaded and executed.”
But there’s more to it than just that. In order to exploit the weakness, Cerrudo said that an attacker likely would need to create a malicious DLL with the same MD5 hash as the benign one and then replace the original one with the DLL containing the exploit code. The attack in this case would be against the MD5 algorithm itself, because the attacker would need to create a second message with the same hash as the known message. Known as a second preimage attack, it is practically out of reach for most individual attackers.
However, Cerrudo says that it may well be possible for an organization such as an intelligence agency that has massive amounts of compute power and resources to be able to execute such an attack. MD5 is known to have a variety of weaknesses, including collision problems, and Microsoft itself stopped including it in its products seven years ago. Cerrudo said that while exploiting the issue he found via a second preimage attack is likely impractical for most attackers, there may be other vectors out there that could accomplish the same task.
“I think that there could be others. I dedicated some time to it, I did research and tried different ways to exploit the issue but this doesn’t mean that I exhausted all possibilities. It’s just a matter of dedicating some time and trying different options like combining this issue with others, abusing some Windows Installer functionality, timing and blocking issues, etc. These are the kind of things I would try if I would have time. I wouldn’t discard that someone can come up with an idea to exploit it,” Cerrudo said via email.
