Hi @ll, Google's software_removal_tool.exe alias Chrome Cleanup Tool loads and executes several DLLs from its "application directory" during runtime: * Windows XP: SetupAPI.dll, NTMarta.dll, ClbCatQ.dll, SRClient.dll, UXTheme.dll, RASAPI32.dll, HNetCfg.dll, IPHlpAPI.dll, RASAdHlp.dll, XPSP2Res.dll, RichEd20.dll, SENSAPI.dll * Windows 7: NTMarta.dll, SRClient.dll, DWMAPI.dll, UXTheme.dll, IPHlpAPI.dll, DNSAPI.dll Additionally the following DLLs are loaded from its "application directory" during load-time: WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll For software downloaded with a web browser the application directory 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> for "prior art" about this well-known and well-documented vulnerability. If an attacker places the DLLs named above in the users "Downloads" directory (for example per drive-by download or social engineering) this vulnerability becomes a remote code execution. See <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://seclists.org/fulldisclosure/2015/Dec/121> Proof of concept (verified on Windows XP and Windows 7 using version 2.46 and 6.44.3.0 of software_removal_tool.exe): 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save it as UXTheme.dll in your "Downloads" directory, then copy it as RichEd20.dll, ClbCatQ.dll, SetupAPI.dll, DWMAPI.dll etc.; 2. download software_removal_tool.exe and save it in your "Downloads" directory; 3. run software_removal_tool.exe from the "Downloads" directory; 4. notice the message boxes displayed from the DLLs placed in step 1. PWNED! 5. create empty files WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll in your "Downloads" directory; 6. run software_removal_tool.exe from the "Downloads" directory. DOSSED! This denial of service can easily turned into arbitrary code execution too: just create a DLL with all the entries referenced from software_removal_tool.exe. For this well-known (trivial, easy to avoid, easy to detect and easy to fix) beginner's error see <https://capec.mitre.org/data/definitions/471.html>, <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> plus <http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>: | To ensure secure loading of libraries | * Use proper DLL search order. | * Always specify the fully qualified path when the library location ~~~~~~ | is constant. Additionally software_removal_tool.exe uses an UNSAFE temporary directory %TEMP%\scoped_dir<pid>_<random>\ to extract and run %TEMP%\scoped_dir<pid>_<random>\ChromeRecovery.exe For this well-known (trivial, easy to avoid, easy to detect and easy to fix) beginner's error see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html> plus <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> stay tuned Stefan Kanthak Timeline: ~~~~~~~~~ 2016-01-28 sent vulnerability report to <security@google.com> NO reply 2016-02-05 resent vulnerability report to <security@google.com> 2016-02-10 reply from Google security team: "Chrome is not in scope for the Google VRP program, and has a separate bug reporting process." 2016-02-10 resent vulnerability report to <security@chromium.org> NO reply, not even an acknowledgement of receipt 2016-02-24 resent vulnerability report to <security@chromium.org> and <security@google.com> 2016-02-24 reply from Google security team: "This is working as intended." Google want's to have your Windows pwned! 2016-02-24 completely clueless reply from Chromium telling that they didn't read <http://seclists.org/fulldisclosure/2015/Nov/101> and <http://seclists.org/fulldisclosure/2015/Dec/86> plus <http://seclists.org/fulldisclosure/2015/Dec/121>: "I'm also unsure what defenses you intended to propose here, because the loader definitely pulls in many (all?) of those imports prior to any application code running -- so things like SetDefaultDllDirectories simply aren't a viable defense." 2016-02-24 OUCH! The DLLs loaded during runtime (see steps 1 to 4) don't have any exports, there is no import which can (or need to) be pulled by the loader. 2016-02-26 another nonsense reply from Chromium 2016-02-26 report published obviously neither Google nor Chromium seem to be interested in fixing their vulnerable cleanup tool. STAY AWAY FROM SUCH CRAPWARE!