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!