Google Chrome Cleanup Tool DLL Hijacking

`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 <[email protected]>  
  
NO reply  
  
2016-02-05 resent vulnerability report to <[email protected]>  
  
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 <[email protected]>  
  
NO reply, not even an acknowledgement of receipt  
  
2016-02-24 resent vulnerability report to <[email protected]>  
and <[email protected]>  
  
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!  
`