###########################

# Google Chrome Cleanup Tool DLL Hijacking Vulnerability

###########################

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!

###########################

# Iranian Exploit DataBase = http://IeDb.Ir [2016-03-03]

###########################