Back to list
[ADV170017] Defense in depth -- the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy
May 08 2018 10:01PM
Stefan Kanthak (stefan kanthak nexgo de)
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:
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:
Microsoft published plenty advice/guidance to avoid this beginner's
... 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%
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>)
3. notice the message boxes displayed from the DLLs saved in
PS: be sure to read
and update your installation media!
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
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
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
2018-03-12 sent congratulation due to 1st anniversary to Microsoft,
plus a status request, announcing a 45 day deadline for
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
2018-05-08 report published
[ reply ]
Copyright 2010, SecurityFocus