BugTraq
Executable installers are vulnerable^WEVIL (case 28): Google's Chrome cleanup tool allows arbitrary (remote) code execution WITH escalation of privilege Feb 26 2016 03:44PM
Stefan Kanthak (stefan kanthak nexgo de)
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.a
spx>:

| 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 (at) google (dot) com [email concealed]>

NO reply

2016-02-05 resent vulnerability report to <security (at) google (dot) com [email concealed]>

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 (at) chromium (dot) org [email concealed]>

NO reply, not even an acknowledgement of receipt

2016-02-24 resent vulnerability report to <security (at) chromium (dot) org [email concealed]>
and <security (at) google (dot) com [email concealed]>

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!

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus