Hi @ll,

the MSDN article "Security Considerations: Microsoft Windows Shell"
<https://msdn.microsoft.com/en-us/library/bb776776.aspx#shellexecute-shellexecuteex-and-related-functions>
provides since MANY years the following advice for calls of ShellExecute():

| Make sure you provide an unambiguous definition of the application that is to
| be executed.
|
| * When providing the executable file's path, provide the fully qualified path.
|   Do not depend on the Shell to locate the file.


Now peek into the code of C:\Windows\Write.exe and discover the following
surprise:

    ShellExecuteW(NULL, NULL, L"wordpad.exe", L"...", NULL, 10);


Continue with the MSDN artice "Application Registration"
<https://msdn.microsoft.com/en-us/library/ee872121.aspx#finding-an-application-executable>:

| When the ShellExecuteEx function is called with the name of an executable file
| in its lpFile parameter, there are several places where the function looks for
| the file. We recommend registering your application in the App Paths registry
| subkey. Doing so avoids the need for applications to modify the system PATH
| environment variable.
|
| The file is sought in the following locations:
| * The current working directory.
| * The Windows directory only (no subdirectories are searched).
| * The Windows\System32 directory.
| * Directories listed in the PATH environment variable.
| * Recommended:
|   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
...
| In Windows 7 and later, we strongly recommend you install applications per
| user rather than per machine. An application that is installed for per user
| can be registered under
| HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths.


Demonstration:
~~~~~~~~~~~~~~

0. Log on to the "protected" administrator account created during the
   installation of Windows.

1. Execute C:\Windows\write.exe per double-click or via command line:
   this starts WordPad.

2. Add the registry entry

   [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\wordpad.exe]
   @="C:\\Windows\\system32\\cmd.exe"

   for example via the command line

   REG.exe ADD "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\wordpad.exe" /VE /T REG_SZ /D 
"%COMSPEC%"

3. Repeat step 2: now the command processor starts instead of
   WordPad.

4. Start Windows^WFile Explorer, open the Windows directory, right-
   click on C:\Windows\write.exe to display its context menu, then
   click on the "Run as administrator" entry and acknowledge the
   UAC prompt: on recent versions of Windows this starts WordPad,
   on older versions but the command processor (both of course
   elevated).


See <https://cwe.mitre.org/data/definitions/426.html>
and <https://cwe.mitre.org/data/definitions/427.html>
plus <https://capec.mitre.org/data/definitions/471.html>
for the classification of this well-documented weakness and attack.


The demonstration exploits 2 bugs: the first is the unqualified simple
filename used by Write.exe in the call of ShellExecute(); the second bug
is in ShellExecute(), which evaluates the USER-writable registry key

   [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths]

when running elevated with a split token on older versions of Windows!


stay tuned and for away from software riddled with beginner's errors
Stefan Kanthak


PS: compare the behaviour of ShellExecute() to that of COM, as
    documented in <https://msdn.microsoft.com/en-us/library/bb756926.aspx>:

| Beginning with Windows Vista® and Windows Server® 2008, if the integrity
| level of a process is higher than Medium, the COM runtime ignores per-
| user COM configuration and accesses only per-machine COM configuration.
| This action reduces the surface area for elevation of privilege attacks,
| preventing a process with standard user privileges from configuring a
| COM object with arbitrary code and having this code called from an
| elevated process.