On other versions of Windows this list changes, but the vulnerableexecutable installer always loads and executes some DLLs from its"application directory".

This weakness is well-known and well-documented: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>.

See <https://technet.microsoft.com/en-us/library/2269637.aspx>,<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and<https://msdn.microsoft.com/en-us/library/ms682586.aspx> formitigations of this beginner's error.

For software downloaded with a web browser the "applicationdirectory" is typically the user's "Downloads" directory: see<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>and <http://seclists.org/fulldisclosure/2012/Aug/134>

If an attacker places one of the DLLs named above in the users"Downloads" directory (for example per drive-by download, socialengineering, ...) this vulnerability becomes a remote codeexecution WITH escalation of privilege.

It creates a subdirectory ns<letter><random_hex_value>.tmp in %TEMP%where it extracts multiple DLLs to and executes them.This subdirectory inherits the access rights of its parent %TEMP%,so an unprivileged attacker^Wuser can replace the DLLs between theircreation and execution, again resulting in arbitrary code executionwith escalation of privilege.

See <https://cwe.mitre.org/data/definitions/377.html> and<https://cwe.mitre.org/data/definitions/379.html> for thiswell-known and well-documented weakness.