Date: Wed, 9 May 2018 00:01:59 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <fulldisclosure@...lists.org>
Subject: [ADV170017] Defense in depth -- the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy

Hi @ll,

during installation of Microsoft Office 2003 and newer versions
as well as single components of Microsoft Office products, the
executable of the "Office Source Engine", ose.exe, is copied as
"%TEMP%\ose00000.exe" and then executed with elevated privileges.

%TEMP% is writable by unprivileged users, using it to store and
then run vulnerable executables with elevated privileges is a
well-known and well-documented beginner's error:
see <https://cwe.mitre.org/data/definitions/377.html>
and <https://cwe.mitre.org/data/definitions/379.html>.
plus <https://capec.mitre.org/data/definitions/29.html>

JFTR: when a (unattended) installation of Microsoft Office is run
      under SYSTEM account, %TEMP% resolves to %SystemRoot%\Temp\


ose.exe is vulnerable to DLL hijacking: it loads multiple Windows
system DLLs from %TEMP% (its "application directory") instead from
Windows' "system directory" %SystemRoot%\System32\

Dll hijacking is a well-known and well-documented vulnerability:
see <https://cwe.mitre.org/data/definitions/426.html>
and <https://cwe.mitre.org/data/definitions/427.html>,
plus <https://capec.mitre.org/data/definitions/471.html>


Microsoft published plenty advice/guidance to avoid this beginner's
error: <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://support.microsoft.com/en-us/help/2389418/secure-loading-of-libraries-to-prevent-dll-preloading-attacks>
and
<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>
... which their own developers and their QA but seem to ignore!


Proof of concept:
~~~~~~~~~~~~~~~~~

On a fully patched Windows 7 SP1

1. fetch <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
   and save it as RSAEnh.dll and/or CryptBase.dll in your %TEMP%
   directory.

2. start the installation of Microsoft Office 2010: use for example
   a product DVD or the installers X17-22390.exe/X17-75062.exe
   available from MSDN or (via <http://www.office.com/backup>)
   from <https://go.microsoft.com/fwlink/p/?LinkID=403713>

3. notice the message boxes displayed from the DLLs saved in
   %TEMP%!


stay tuned
Stefan Kanthak


PS: be sure to read
    <https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170017>
    and update your installation media!


Timeline:
~~~~~~~~~

2017-03-12    vulnerability report sent to Microsoft

2017-03-13    reply from Microsoft: "case 37732 opened"

2017-05-13    query from Microsoft, asking for acknowledgement
              information

2017-05-13    sent acknowledgement information to Microsoft

2017-09-30    notification from Microsoft:
              "We have completed our investigation related to the fix
               for this issue and will be releasing defense-in-depth
               fix in our Oct patch Tuesday release."

2017-10-16    notification from Microsoft:
              "this issue was fixed as-planned on 10/10"

2017-10-16    requested information about CVE identifier(s) assigned

2017-10-19    reply from Microsoft:
              "no CVE identifier assigned; this is a defense-in-depth
               fix, which we dont consider as vulnerability.
               In this case, ose.exe is operating by-design to search
               the application directory for DLLs. Unfortunately this
               does enable the planting of malicious DLLs in the
               install directory, as you mentioned. Because the behavior
               was by-design, we didn't issue a CVE. We did, however,
               improve product functionality here in order to mitigate
               the issue."

2017-10-19    OUCH: no, you did NOT fix this vulnerability!

              On a fully patched Windows 7 SP1, the "fixed" OSE.EXE
              for Office 2010 still loads Version.dll, WinHTTP.dll
              and WebIO.dll from its application directory, and the
              "fixed" OSE.EXE for Office 2013 still loads Version.dll;
              only the fixed OSE.EXE for Office 2016 seems not to be
              vulnerable any more: is has NO load-time dependency,
              only runtime dependencies.

              You also failed to provide fixed installation media!

2017-10-20    reply from Microsoft:
              "the Defense-in-Depth fix was to modify the installation
               process to restrict ose.exe such that it only searches
               System folders, and does not search %TEMP% for DLLs or
               load them from this folder."

2017-10-20    longer mail about their misconceptions, the difference
              between (implicit) load-time and (expicit) runtime
              linking, and several proposals how to REALLY fix this
              vulnerability sent to Microsoft

2017-10-21    reply from Microsoft:
              "thanks for the detailed and technical feedback.
               I've sent it to our engineering team ..."

2017-12-13    sent status request to Microsoft: what's going on.

2017-12-15    reply from Microsoft:
              "I've been discussing this with the product team and
               they did agree with your points from your last messages.
               I've reopened this case and re-engaged engineering to
               assess this issue again. We've also engaged a secondary
               team in regards to evaluating another potential patch or
               DiD fix. Apologies for the lack of updates - I'll be sure
               to get back to you soon with something more concrete."

2018-02-18    final note and status request sent to Microsoft:
              you promised to get back soon about TWO month ago!

2018-02-20    reply from Microsoft:
              "I sincerely hope that you will continue working with us
               until we are able to address your concerns prior to
               disclosing, as the product teams are actively engaged and
               working on this.
               In regards to the specific status of this case, and
               relating to your suggestions for modifying the installer
               behavior (focused around OSE.EXE), I'd like to reiterate
               that we do agree that your suggestions are valid, and are
               working to re-evaluate the original fix for potential
               modifications. We're also investigating potential fixes
               based on your suggestions relating to the executable
               installers. I'll be sure to keep you updated as we make
               progress here."

2018-03-12    sent congratulation due to 1st anniversary to Microsoft,
              plus a status request, announcing a 45 day deadline for
              public disclosure

2018-03-15    reply from Microsoft:
              "I've escalated internally to get a status update for
               you from the product team, and I hope to have an
               update for you within the next couple of days."

2018-03-23    reply from Microsoft:
              "We are tentatively planning on releasing an updated fix
               for ose.exe and for self-extracting executables in our
               May Patch Tuesday update. We're also planning on updating
               documentation describing actions users will have to take
               as far as updating installation media, as appropriate.
               I think your 45 day SLA lands the disclosure date around
               April 26. Would it be possible to delay this until after
               we can publish the update on 5/8?

2018-03-23    agreed to postpone public disclosure until after May 2018
              patch tuesday

2018-05-08    report published

Powered by blists - more mailing lists