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
