[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Executable installers are vulnerable^WEVIL (case 28): Google's Chrome cleanup tool allows arbitrary (remote) code execution WITH escalation of privilege

Hi @ll,

Google's software_removal_tool.exe alias Chrome Cleanup Tool loads
and executes several DLLs from its "application directory" during

* 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,

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
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 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.


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.


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://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus

| 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

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

stay tuned
Stefan Kanthak


2016-01-28    sent vulnerability report to <security@xxxxxxxxxx>

              NO reply

2016-02-05    resent vulnerability report to <security@xxxxxxxxxx>

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@xxxxxxxxxxxx>

              NO reply, not even an acknowledgement of receipt

2016-02-24    resent vulnerability report to <security@xxxxxxxxxxxx>
              and <security@xxxxxxxxxx>

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.