2013-05-19-Part-1-the-microsoft-way

This vulnerability no longer exists in most modern Windows systems.

The "Microsoft Installer" creates for applications installed via an
.MSI the following uninstall information in the Windows registry
(see <http://msdn.microsoft.com/library/aa372105.aspx>):



[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall]
"UninstallString"="MsiExec.Exe /X{<GUID>}"
"ModifyPath"="MsiExec.Exe /I{<GUID>}"

Note the unqualified path to the executable "msiexec.exe".

On Windows installations without the "SafeProcessSearchMode" hotfix
(cf. <http://support.microsoft.com/kb/905890>) or with this safeguard
turned off (cf. <http://msdn.microsoft.com/library/dd266735.aspx>,
which refers to <http://support.microsoft.com/kb/959426> alias MS09-015),
an executable "msiexec.exe" placed in the CWD or the users "base"
directory (addressed by "%HOMEDRIVE%%HOMEPATH%" and typically equal to
"%USERPROFILE%") can be run instead of the intended executable
"%SystemRoot%\System32\MsiExec.Exe".


The VERY simple fix (which eliminates this attack vector completely):
always use fully-qualified paths to the well-known executables.

JFTR: cf. <http://seclists.org/fulldisclosure/2011/Sep/160>

Stefan Kanthak




🧠 What's the main idea?

The Windows Installer writes something like this in the registry for uninstalling/modifying programs:

MsiExec.exe /X{GUID}
MsiExec.exe /I{GUID}

Notice the important detail:
👉 It does not use the full executable path.
It just says MsiExec.exe, instead of:

C:\Windows\System32\MsiExec.exe /X{GUID}

This seems harmless, but that's where the problem lies.

💥 Where's the vulnerability?

In some Windows versions/configurations (especially without SafeProcessSearchMode):

When Windows tries to run:

MsiExec.exe

It searches for the file in this order (simplified):

1. Current Working Directory (CWD) (write cwd in powershell or cd in CMD)
2. User folder (%USERPROFILE%, %HOMEDRIVE%%HOMEPATH%)
3. System folders (e.g., System32)
4. Other PATH folders…

That is:
⚠️ If a fake msiexec.exe exists in the user's folder or the current folder, Windows might execute the malicious file instead of the genuine one.

🧨 How does this turn into a practical exploit?

An attacker can:

1. Place a malicious msiexec.exe in the user's folder (or in a folder where a process will be executed from)
2. Induce the user (or the system) to:
   • Uninstall a program
   • Modify an MSI
   • Or perform any action that triggers MsiExec.exe via the registry

Windows executes:
❌ The fake msiexec.exe
✅ Instead of C:\Windows\System32\msiexec.exe

Result:
🚨 Arbitrary code execution with the privileges of the process that called the uninstall/modify.

Depending on the context, this can lead to:

• Persistence
• Privilege Escalation
• Malware execution
• Backdoors, etc.

🔥 Why is this serious?

Because:

• It's silent
• Exploits default Windows behavior
• Doesn't require breaking anything sophisticated
• Relies solely on the executable search order
• Has been the cause of several historic CVEs

✅ The fix is ridiculously simple

Instead of:

MsiExec.exe /X{GUID}

Use:

C:\Windows\System32\MsiExec.exe /X{GUID}

In other words:
✔️ Always use a fully-qualified path for critical executables.

This completely eliminates this attack vector.

🛡️ What about SafeProcessSearchMode?

It's a Microsoft mitigation that:

• Changes the executable search order
• Reduces the chance of picking up the .exe from the wrong folder
• Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

However:

• It might be disabled
• It might not exist on older versions
• It's not as secure as using an absolute path

That's why the text says:

"The VERY simple fix: always use fully-qualified paths"

📌 Summary in one sentence

This vulnerability allows a malicious msiexec.exe to be executed instead of the original because Windows was instructed to run the executable without a full path, relying on the file search order.