![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/Schutz.jpg\")
Microsoft pflegt seit Jahren eine wandelnde Sicherheitsl\u00fccke im Office-Installer, der f\u00fcr einzelne Anwendungen oder das gesamte Paket verwendet wird. Eigentlich sollte die Sicherheitsl\u00fccke zum 10. Oktober 2017 (ADV170017) und nochmals zum 8. Mai 2018 mittels eines Sicherheitsupdates (Office-Defense in Depth Update) behoben sein. Aber Microsoft hat mehrfach gepatzt.<\/p>\n
<\/p>\n
An dieser Stelle mein Dank an Stefan Kanthak, dass er die Informationen vorab mit mir geteilt hat. Und vor allem ein Dank f\u00fcr seine Geduld \u2013 ich habe hier eine Menge Holz von ihm als Fragmente herum liegen, die Schritt f\u00fcr Schritt als Blog-Beitr\u00e4ge zur Ver\u00f6ffentlichung vorgesehen sind. Aber es gibt halt immer so viel anderen brandhei\u00dfen Schei\u00df, der auch raus muss \u2013 und dann fehlt die Zeit f\u00fcr die Aufbereitung der Beitr\u00e4ge. Aber i.d.R. geht hier nix verloren \u2013 auch keine der vielen Lesertipps \u2013 ich hole immer mal wieder was aus meinen 'Kisten' hervor und bereite es als Blog-Beitrag auf. <\/p>\n<\/blockquote>\n Stefan Kanthak hat mir folgende Informationen bereitgestellt, die ich mal f\u00fcr deutschsprachige Leser etwas aufbereite.<\/p>\n during installation of Microsoft Office 2003 and newer versions Seit Office 2003 verwendet Microsoft die Office Source Engine, ose.exe<\/em>, zum Updaten und Installieren. Das Problem dabei besteht darin, dass die ose.exe <\/em>in den tempor\u00e4ren Ordner als:<\/p>\n %TEMP%\\ose00000.exe<\/p>\n kopiert und dann mit erh\u00f6hten Rechten ausgef\u00fchrt wird. Auf dem Ordner %TEMP%<\/em> haben aber alle, auch nicht privilegierte (Standard)-Nutzerkonten, sowohl Schreib- als auch Ausf\u00fchrungsrechte. <\/p>\n Anmerkung: Wird Microsoft Office per (unattended) Installation auf das System gebracht, l\u00e4uft es unter einem SYSTEM-Konto. Dann wird statt des Ordners %TEMP% halt %SystemRoot%\\Temp\\ verwendet, was aber keinen Unterschied macht.<\/p>\n<\/blockquote>\n Wenn es also einer Malware gelingt, Dateien in diesem Ordner abzulegen (die Berechtigungen sprechen nicht dagegen) und per DLL-Hijacking zur Ausf\u00fchrung zu bringen, k\u00f6nnen Angreifer \u00fcber ose.exe <\/em>administrative Berechtigungen erhalten. <\/p>\n Anmerkung: DLL-Hijacking ist ein passiver Angriff, der aktive Teil ist hier das Programm OSE[00000].exe, das \u00fcber ein Dutzend DLLs aus %TEMP% l\u00e4dt.<\/p>\n<\/blockquote>\n Kein Rocket-Science, das ist alles l\u00e4ngst bekannt. Stefan Kanthak schreibt dazu: <\/p>\n %TEMP% is writable by unprivileged users, using it to store and Das Ganze wurde bereits unz\u00e4hlige Male f\u00fcr Entwickler in der Liste der Top-Software-Fehler, die man wirklich vermeiden sollte, dokumentiert. Hier drei Fundstellen, die Stefan Kanthak mir gemailt hat:<\/p>\n CWE-377: Insecure Temporary File<\/a> Die Erkenntnis: (Fast) alle Programme (\u00fcbrigens auch Sachen wie z.B. Microsofts Sicherheitsupdates), die in %TEMP% Dateien entpacken und zur Ausf\u00fchrung bringen, sind f\u00fcr DLL-Hijacking anf\u00e4llig. Und noch schlimmer: Die zum Schlie\u00dfen der Schwachstelle bereitgestellten Fixes sind selbst f\u00fcr DLL-Hijacking anf\u00e4llig! Stefan Kanthak schreibt dazu: <\/p>\n ose.exe is vulnerable to DLL hijacking: it loads multiple Windows Angreifer brauchen nur bestimmte DLLs in den Ordner %TEMP% zu speichern. Gibt es Abh\u00e4ngigkeiten zu diesen DLLs in der ose.exe<\/em>, l\u00e4dt Windows diese, anstatt die DLLs aus den Windows-Verzeichnissen zu beziehen. Sind die so geladenen DLLs kompromittiert, hat der Angreifer die Kontrolle und kann die Privilegien des Installers f\u00fcr seine Zwecke nutzen. <\/p>\n Es gibt in Windows einen Mechanismus der 'Known good DLLs', der das Problem vermeiden k\u00f6nnte \u2013 das Ganze ist hier seit 2004 beschrieben<\/a>. Scheint aber wohl nicht genutzt zu werden. Angemerkt sei aber, dass die \"Known DLLs\" prim\u00e4r eine Ma\u00dfnahme zur Performance-Steigerung sind. Sekund\u00e4r bieten sie aber eine (schwache) Sicherheitsma\u00dfnahme, die aber seit Windows 2000 durch \"DLL redirection\" (<filename>.exe.local) und seit Stefan Kanthak schrieb mir, dass DLL-Hijacking nun nichts wirklich neues sei, vielmehr ist diese Technik zur Ausnutzung einer Schwachstelle seit vielen Jahren bestens bekannt und dokumentiert. Er verweist auf folgende Fundstellen, die auch Microsoft bekannt sein m\u00fcssten.<\/p>\n CWE-426: Untrusted Search Path<\/a> Nun k\u00f6nnte man noch argumentieren, dass Microsofts Leute m\u00f6glicherweise nicht auf fremden Webseiten mitlesen. Aber das Unternehmen ver\u00f6ffentlicht ja eigenen Anleitungen f\u00fcr Programmieranf\u00e4nger:<\/p>\n Dynamic-Link Library Security<\/a> Es gibt sicher noch mehr Webseiten von Microsoft zum Thema. Die spannende Frage ist nun, ob Microsofts Entwickler die eigenen Dokumentation nicht lesen oder nicht verstanden haben? Denn anders ist die Ignoranz nicht zu erkl\u00e4ren. <\/p>\n Stefan Kanthak hat ein Proof of Concept, wie sich diese Schwachstelle ausnutzen l\u00e4sst, ver\u00f6ffentlicht. Hierzu schreibt er folgendes. <\/p>\n Proof of concept: On a fully patched Windows 7 SP1<\/p>\n 1. fetch <https:\/\/skanthak.homepage.t-online.de\/download\/SENTINEL.DLL<\/a>> and save it as RSAEnh.dll and\/or CryptBase.dll in your %TEMP% directory.<\/p>\n 2. start the installation of Microsoft Office 2010: use for example 3. notice the message boxes displayed from the DLLs saved in Interessant ist die Konversation zwischen Stefan Kanthak und Microsoft, der diese Schwachstelle an das Unternehmen gemeldet hat. Ich poste das mal ohne Kommentar:<\/p>\n Timeline: 2017-03-12 vulnerability report sent to Microsoft<\/p>\n 2017-03-13 reply from Microsoft: \"case 37732 opened\"<\/p>\n 2017-05-13 query from Microsoft, asking for acknowledgement 2017-05-13 sent acknowledgement information to Microsoft<\/p>\n 2017-09-30 notification from Microsoft: 2017-10-16 notification from Microsoft: 2017-10-16 requested information about CVE identifier(s) assigned<\/p>\n 2017-10-19 reply from Microsoft: 2017-10-19 OUCH: no, you did NOT fix this vulnerability!<\/p>\n On a fully patched Windows 7 SP1, the \"fixed\" OSE.EXE You also failed to provide fixed installation media!<\/p>\n 2017-10-20 reply from Microsoft: 2017-10-20 longer mail about their misconceptions, the difference 2017-10-21 reply from Microsoft: 2017-12-13 sent status request to Microsoft: what's going on.<\/p>\n 2017-12-15 reply from Microsoft: 2018-02-18 final note and status request sent to Microsoft: 2018-02-20 reply from Microsoft: 2018-03-12 sent congratulation due to 1st anniversary to Microsoft, 2018-03-15 reply from Microsoft: 2018-03-23 reply from Microsoft: 2018-03-23 agreed to postpone public disclosure until after May 2018 2018-05-08 report published<\/p>\n<\/blockquote>\n In einem Mail-Austausch zwischen Stefan Kanthak und dem Microsoft Security Response Center-Team, der mir vorliegt, erbat sich das MSRC-Team noch ein paar Tage Aufschub zur Ver\u00f6ffentlichung. Hier der Auszug aus einer Mail von Stefan Kanthak an das MSRC-Team:<\/p>\n > Was there a specific timeline upon which you were planning to disclose?<\/p>\n It's overdue! You\/Microsoft can't request responsible disclosure when youself don't act responsible too: I reported the vulnerability about 11 months ago, and it took your developers more than 6 months to come up with a \"fix\" that overlooked 2 of 3 paths.<\/p>\n<\/blockquote>\n JFTR: DLL hijacking (more precise: DLL search order hijacking) is VERY WELL-known and WELL-documented for more that 20 years.<\/p>\n<\/blockquote>\n I hope that you expressed your congratulations to David LeBlanc > I sincerely hope that you will continue working with us until we are > In regards to the specific status of this case, and relating to JFTR: please ask your customers who deploy Microsoft Office per unattended installation whether their deployment tools run under SYSTEM account, ie. use %SystemRoot%\\Temp\\, then take a look at<\/a>.<\/p>\n<\/blockquote>\n Die mit '>' beginnenden Zeilen sind die Antwort des Microsoft Mitarbeiters aus dem MSRC-Team. Und hier der Auszug aus der n\u00e4chsten Antwort-Mail, in der Microsoft verspricht, die Kuh vom Eis zu holen:<\/p>\n > Thanks for your patience up to this point and for coordinating with > We're also planning on updating documentation describing actions users OK, I REALLY appreciate that.<\/p>\n > I think your 45 day SLA lands the disclosure date around April 26. I'll delay the disclosure until after the May patch tuesday.<\/p>\n<\/blockquote>\n Der Bitte, die Ver\u00f6ffentlichung bis zum Mai-Patchday (8.5.2018) zu verschieben, wurde also stattgegeben. <\/p>\n Gem\u00e4\u00df Historie gab es bereits im Oktober 2017 den Versuch Microsofts, diese Schwachstelle in ose.exe <\/em>zu schlie\u00dfen. Das ging aber in die Hose, wie diese Antwort von Stefan Kanthak auf die R\u00fcckmeldung des MSRC-Teams belegt.<\/p>\n >>>> Hi Travis\/MSRC, Das ging daneben, wie Stefan Kanthak gegen\u00fcber den Microsoft-Leuten demonstriert. Ich habe an dieser Stelle nur Ausz\u00fcge aus einem Mail-Verkehr herausgezogen. Stefan Kanthak hat jeweils mehrfach nachgehakt, wie der Status der Geschichte ist und dann irgendwann auch eine Antwort von Microsoft bekommen. An dieser Stelle kann man die Stirn runzeln \u2013 aber Microsoft hatte ja einen weiteren Schuss frei. Im Mai 2018 sollte es soweit sein (Aussage des MSRC-Teams).<\/p>\n Im Advisory ADV170017 (ADV170017 | Microsoft Office Defense in Depth Update) vom 8. Mai 2018 geht Microsoft auf das Problem ein und ver\u00f6ffentlicht ein Sicherheitsupdate f\u00fcr Office 2010 bis Office 2016, welches die Schwachstelle ausb\u00fcgeln soll. <\/p>\n Beachtet, dass die Fixes nur noch Microsoft Office 2010, 2013 und 2016 beinhalten \u2013 im Oktober 2017 w\u00e4re zumindest noch Microsoft Office 2007 dabei gewesen. <\/p>\n<\/blockquote>\n Man k\u00f6nnte nun ja sagen: Was lange braucht, wird endlich gut \u2013 obwohl ich bei Microsoft da mittlerweile so meine Zweifel habe. Das wurde auch mal wieder prompt best\u00e4tigt, denn Stefan Kanthak schickte mir vor einigen Tagen eine zweite Mail mit folgendem Inhalt:<\/p>\n Hi Travis,<\/p>\n > Hello Stefan, Dump them, they are STILL vulnerable! | On a fully patched Windows 7 SP1, the \"fixed\" OSE.EXE installed by The ose.exe published yesterday still show this behaviour! > and the associated advisory was updated, I'm going to go ahead and Why? The vulnerability still persists! > If you have any questions or concerns, please feel free to respond Not amused! PS: I miss my name in the acknowledgements for the May 2018 patchday!<\/p>\n<\/blockquote>\n Tja, mir fehlen irgendwie die Worte. Man hat irgend etwas gestopft, was in dieses Internet geschrieben und ist der Meinung, man k\u00f6nne den Fall nun bei Microsoft schlie\u00dfen. Aber Stefan Kanthak weist darauf hin, dass sich im Grunde nix ge\u00e4ndert hat, denn die neu ausgelieferte ose.exe <\/em>hat weiterhin Modulabh\u00e4ngigkeiten und wird im Ordner %Temp% <\/em>abgelegte Dateien wie Version.dll<\/em>, WinHTTP.dll <\/em>und WebIO.dll <\/em>ungepr\u00fcft nachladen. <\/p>\n Der Ratschlag von Stefan Kanthak lautet, dass Office-Setup-Team samt der Qualit\u00e4tssicherung und dem Management zu feuern und endlich ein paar kompetente Entwickler anzuheuern. Das Problem: Microsoft hat noch eine ganze Hand-voll solcher Baustellen, wo die gleiche So\u00dfe in Gr\u00fcn zu finden ist (ich habe nur noch nicht dr\u00fcber gebloggt). Wenn man also diesen Ratschlag umsetzt, lichten sich wohl die Entwicklerhallen in Redmond \u2013 und mit neuen Entwicklern, die die Sicherheitsthematik drauf haben, gibt es dann das Problem, dass die das Zeugs nicht verstehen, was ihre Vorg\u00e4nger verbrochen haben. Mag da nicht im Detail aus dem N\u00e4hk\u00e4stchen '30 Jahre Erfahrung mit Microsoft' plaudern \u2013 aber mir sind solche F\u00e4lle unter die Augen gekommen.<\/p>\n Anmerkung: Stefan Kanthak schrieb mir dazu 'Solche (auf CAPEC und CWE seit Jahren dokumentierte) Anf\u00e4ngerfehler macht nicht nur Microsoft, sondern alle Firmen und Organisationen, die ausf\u00fchrbare Installationsprogramme bereitstellen: Intel, Google, Microsoft, DropBox, F-Secure, Kaspersky, Avast, AVG, MalwareBytes, Rapid9, Telekom, T-Online, 1&1, WEB.DE, GMX, VideoLAN\/VLC, WinRAR, 7zip, Python for Windows, ActiveState, Secunia PSI, …<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":" Microsoft pflegt seit Jahren eine wandelnde Sicherheitsl\u00fccke im Office-Installer, der f\u00fcr einzelne Anwendungen oder das gesamte Paket verwendet wird. Eigentlich sollte die Sicherheitsl\u00fccke zum 10. Oktober 2017 (ADV170017) und nochmals zum 8. Mai 2018 mittels eines Sicherheitsupdates (Office-Defense in Depth … Weiterlesen Es ist ein leidiges Thema, was ich zum Sonntag auf's Tablet bringe. Ich hatte die Informationen bereits eine ganze Weile von Sicherheitsspezialist Stefan Kanthak<\/a>, samt dem Hinweis, dass Microsoft zugesagt habe, das Problem zum 8. Mai 2018 zu fixen. Einer Offenlegung wurde, laut Stefan Kanthak zugestimmt. Da die Vorwarnzeit lange genug war, publiziere ich die Details an dieser Stelle. Zudem hat Stefan Kanthak die Sachen auf seclists.org in den Beitr\u00e4gen ADV170017] Defense in depth — the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy<\/a> und [ADV170017] Defense in depth — the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy<\/a> ver\u00f6ffentlicht.<\/p>\n
\n
Das Problem mit dem ose.exe-Installer<\/h2>\n
\n
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.<\/p>\n<\/blockquote>\n\n
\n
Programmierfehler als don't l\u00e4ngst bekannt<\/h3>\n
\n
then run vulnerable executables with elevated privileges is a
well-known and well-documented beginner's error<\/p>\n<\/blockquote>\n
CWE-379: Creation of Temporary File in Directory with Incorrect Permissions<\/a>
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions<\/a><\/p>\nWas ist DLL-Hijacking?<\/h3>\n
\n
system DLLs from %TEMP% (its \"application directory\") instead from
Windows' \"system directory\" %SystemRoot%\\System32\\<\/p>\n<\/blockquote>\n\n
Windows XP durch \"application manifests\" TRIVIAL ausgehebelt werden
kann. Details zu letzterem sind im Beitrag DLL Minesweeper<\/a> durch Stefan Kanthak demonstriert (siehe den optionalen Schritt 3).<\/p>\n<\/blockquote>\nDLL-Hijacking ist bestens dokumentiert<\/h3>\n
CWE-427: Uncontrolled Search Path Element<\/a>
CAPEC-471: DLL Search Order Hijacking<\/a><\/p>\n
Microsoft Security Advisory 2269637<\/a>
Secure loading of libraries to prevent DLL preloading attacks<\/a>
Load Library Safely<\/a><\/p>\nEin Proof of Concept<\/h2>\n
\n
~~~~~~~~~~~~~~~~~<\/p>\n
a product DVD or the installers X17-22390.exe\/X17-75062.exe
available from MSDN or (via <http:\/\/www.office.com\/backup<\/a>>)
from <https:\/\/go.microsoft.com\/fwlink\/p\/?LinkID=403713><\/p>\n
%TEMP%!<\/p>\n<\/blockquote>\nDie Historie der Schwachstelle<\/h2>\n
\n
~~~~~~~~~<\/p>\n
information<\/p>\n
\"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.\"<\/p>\n
\"this issue was fixed as-planned on 10\/10\"<\/p>\n
\"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.\"<\/p>\n
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.<\/p>\n
\"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.\"<\/p>\n
between (implicit) load-time and (expicit) runtime
linking, and several proposals how to REALLY fix this
vulnerability sent to Microsoft<\/p>\n
\"thanks for the detailed and technical feedback.
I've sent it to our engineering team …\"<\/p>\n
\"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.\"<\/p>\n
you promised to get back soon about TWO month ago!<\/p>\n
\"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.\"<\/p>\n
plus a status request, announcing a 45 day deadline for
public disclosure<\/p>\n
\"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.\"<\/p>\n
\"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?<\/p>\n
patch tuesday<\/p>\n\n
If I would STRICTLY follow my own policy, I had it disclosed in late December already, 45 days after your last reply. On December 13, I sent a notification and requested the status … but got no reply at all.<\/p>\n\n
\n
today: his blog post has its 10th (in words: TENTH) anniversary!
<see<\/a>><\/p>\n
> able to address your concerns prior to disclosing, as the product
> teams are actively engaged and working on this.
Yes, under the condition that you report progress!<\/p>\n
> 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.
OK. I take your word.<\/p>\n\n
> us on disclosure. I'll get back to you as soon as possible with any
> updates.
OK.
I take your word.
Don't disappoint me.<\/p>\n<\/blockquote>\n\n
> will have to take as far as updating installation media, as appropriate.<\/p>\n
> Would it be possible to delay this until after we can publish the
> update on 5\/8?<\/p>\nVersuch, im Oktober 2017 zu fixen<\/h2>\n
\n
>>>>
>>>> this is a followup to TRK:0331000029
>>>>
>>>> The executable installers of ALL (security) updates for ALL
>>>> versions\/products\/components of Microsoft Office allow
>>>> escalation of privilege, they ALL have the same vulnerability
>>>> you tried to fix with the following October 2017 updates:
>>>>
>>>> ose2010-kb2553338-fullfile-x86-glb.exe
>>>> ose2010-kb2553338-fullfile-x64-glb.exe
>>>> osetup2010-kb2837599-fullfile-x86-glb.exe
>>>> osetup2010-kb2837599-fullfile-x64-glb.exe
>>>>
>>>> ose2013-kb3172524-fullfile-x86-glb.exe
>>>> ose2013-kb3172524-fullfile-x64-glb.exe
>>>> osetup2013-kb3172531-fullfile-x86-glb.exe
>>>> osetup2013-kb3172531-fullfile-x64-glb.exe
>>>>
>>>> ose2016-kb4011185-fullfile-x86-glb.exe
>>>> ose2016-kb4011185-fullfile-x64-glb.exe
>>>> osetup2016-kb2920723-fullfile-x86-glb.exe
>>>> osetup2016-kb2920723-fullfile-x64-glb.exe
>>>>
>>>> * Type of issue (buffer overflow, SQL injection, cross-site
>>>> scripting, etc.)
>>>>
>>>> Arbitrary code execution WITH escalation of privilege
>>>>
>>>> * Product and version that contains the bug, or URL if for an
>>>> online service
>>>>
>>>> ALL security updates for ALL Microsoft Office products
>>>> (tested on a fully patched Windows 7 SP1)
>>>>
>>>> * Service packs, security updates, or other updates for the
>>>> product you have installed
>>>>
>>>> n\/a (the vulnerability is in the installer)
>>>>
>>>> * Any special configuration required to reproduce the issue
>>>>
>>>> none
>>>>
>>>> * Step-by-step instructions to reproduce the issue on a fresh
>>>> install
>>>>
>>>> 1. download arbitrary security updates for Microsoft Office,
>>>> for example
<https:\/\/download.microsoft.com\/download\/0\/A\/E\/0AEDE254-6709-41C6-BA7B-8DFDE3C23C10\/ose2016-kb4011185-fullfile-x86-glb.exe<\/a>>
<https:\/\/download.microsoft.com\/download\/E\/E\/4\/EE4720B6-04E0-42F8-8078-7A1FFABD9DB6\/ose2013-kb3172524-fullfile-x86-glb.exe<\/a>>
<https:\/\/download.microsoft.com\/download\/2\/7\/3\/2737636B-EEE4-4BBB-8378-ED08894298C6\/ose2010-kb2553338-fullfile-x86-glb.exe<\/a>>
>>>> and save them in your \"Downloads\" directory;
>>>>
>>>> 2. fetch
>>>> <https:\/\/skanthak.homepage.t-online.de\/download\/SENTINEL.DLL<\/a>>
>>>> and save it as Version.dll in your \"Downloads\" directory;
>>>>
>>>> 3. copy the downloaded Version.dll as Cabinet.dll, UXTheme.dll,
>>>> NTMARTA.dll, AppHelp.dll, SrvCli.dll, CSCAPI.dll, SLC.dll,
>>>> NetUtils.dll and\/or CryptSP.dll;
>>>>
>>>> 4. start the security updates downloaded in step 1;
>>>>
>>>> 5. notice the message boxes displayed from the DLLs planted in
>>>> the \"Downloads\" directory!
>>>>
>>>>
>>>> * Proof-of-concept or exploit code
>>>>
>>>> — SENTINEL.C —
>>>> #pragma comment(lib, \"USER32.LIB\")
>>>>
>>>> #pragma comment(linker, \"\/DLL\")
>>>> #pragma comment(linker, \"\/ENTRY:_DllMainCRTStartup\")
>>>> #pragma comment(linker, \"\/SUBSYSTEM:Windows\")
>>>>
>>>> #include <windows.h>
>>>>
>>>> BOOL WINAPI _DllMainCRTStartup(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
>>>> {
>>>> MessageBoxW((HWND) NULL, L\"pwned\", L\"pwned\", MB_ICONERROR);
>>>> return TRUE;
>>>> }
>>>> — EOF —
>>>>
>>>> Compile and link with CL.EXE \/GS- \/LD SENTINEL.C, then copy
>>>> SENTINEL.DLL as UXTHEME.DLL, CRYPTSP.DLL etc.
>>>>
>>>>
>>>> * Impact of the issue, including how an attacker could exploit
>>>> the issue^WBUG!
>>>>
>>>> Complete compromise of the system via planting of some DLLs in
>>>> the \"Downloads\" directory.
>>>>
>>>> In default\/standard installations of Windows Vista, 7, 8, 8.1
>>>> and 10, the user account created during installation is a
>>>> \"protected\" administrator account and will typically\/routinely
>>>> be used by the unsuspecting user.
>>>> Users who download security updates for Microsoft Office from
>>>> the Microsoft Download Center or the Microsoft Update Catalog
>>>> will typically store them in their \"Downloads\" directory.
>>>> Using the restricted token assigned during login, the
>>>> unprivileged user can write any file, for example the DLLs which
>>>> the security updates for Microsoft Office load from their
>>>> application directory, to the \"Downloads\" directory too.
>>>> \"Thanks\" to their embedded application manifest which specifies
>>>> \"requireAdministrator\" the security update installers are
>>>> executed with the elevated token, resulting in an escalation of
>>>> privilege.
>>>> If an attacker can place one of the above named DLLs per
>>>> \"drive-by download\" into the \"Downloads\" directory, this
>>>> vulnerability results in remote code execution with escalation
>>>> of privilege.
>>>>
>>>>
>>>> regards
>>>> Stefan Kanthak<\/p>\n<\/blockquote>\nMicrosoft ver\u00f6ffentlicht ein Office-Defense in Depth Update<\/h2>\n
\n
Ist die L\u00fccke nun geschlossen?<\/h3>\n
\n
>
> As defense-in-depth updates were released as expected yesterday,<\/p>\n
Please reread my mail from 2017-10-20:<\/p>\n
| ose2010-kb2553338-fullfile-x86-glb.exe still loads Version.dll,
| WinHTTP.dll and WebIO.dll from its application directory, and the
| \"fixed\" OSE.EXE installed by ose2013-kb3172524-fullfile-x86-glb.exe
| still loads Version.dll; only the OSE.EXE from seems not to be
| vulnerable any more: is has NO load-time dependency.<\/p>\n
Please read <https:\/\/skanthak.homepage.t-online.de\/minesweeper.html<\/a>>
and follow the instructions to build a minefield\/testbed.
Since the DLLs named above are load-time dependencies, the vulnerability
can be exploited on EVERY version of Windows where these DLLs are not
defined as \"known\" DLLs.<\/p>\n
> close this case.<\/p>\n
I recommend to fire the whole Office Setup team including their managers
and QA, then hire some COMPETENT developers instead!<\/p>\n
> to this email and I'd be happy to reopen the case.
>
> Thanks again for working with us!<\/p>\n
Stefan Kanthak<\/p>\nDas Allerletzte<\/h2>\n
\n