Microsoft und die Office 20xx-Sicherheitslücke in ose.exe

Microsoft pflegt seit Jahren eine wandelnde Sicherheitslücke im Office-Installer, der für einzelne Anwendungen oder das gesamte Paket verwendet wird. Eigentlich sollte die Sicherheitslücke 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.

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, 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ägen ADV170017] Defense in depth — the Microsoft way (part 54): escalation of privilege during installation of Microsoft Office 20xy und [ADV170017] Defense in depth — the Microsoft way (part 54):    escalation of privilege during installation of Microsoft Office 20xy veröffentlicht.

An dieser Stelle mein Dank an Stefan Kanthak, dass er die Informationen vorab mit mir geteilt hat. Und vor allem ein Dank für seine Geduld – ich habe hier eine Menge Holz von ihm als Fragmente herum liegen, die Schritt für Schritt als Blog-Beiträge zur Veröffentlichung vorgesehen sind. Aber es gibt halt immer so viel anderen brandheißen Scheiß, der auch raus muss – und dann fehlt die Zeit für die Aufbereitung der Beiträge. Aber i.d.R. geht hier nix verloren – auch keine der vielen Lesertipps – ich hole immer mal wieder was aus meinen 'Kisten' hervor und bereite es als Blog-Beitrag auf.

Das Problem mit dem ose.exe-Installer

Stefan Kanthak hat mir folgende Informationen bereitgestellt, die ich mal für deutschsprachige Leser etwas aufbereite.

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.

Seit Office 2003 verwendet Microsoft die Office Source Engine, ose.exe, zum Updaten und Installieren. Das Problem dabei besteht darin, dass die ose.exe in den temporären Ordner als:

%TEMP%\ose00000.exe

kopiert und dann mit erhöhten Rechten ausgeführt wird. Auf dem Ordner %TEMP% haben aber alle, auch nicht privilegierte (Standard)-Nutzerkonten, sowohl Schreib- als auch Ausführungsrechte.

Anmerkung: Wird Microsoft Office per (unattended) Installation auf das System gebracht, läuft es unter einem SYSTEM-Konto. Dann wird statt des Ordners %TEMP% halt %SystemRoot%\Temp\ verwendet, was aber keinen Unterschied macht.

Wenn es also einer Malware gelingt, Dateien in diesem Ordner abzulegen (die Berechtigungen sprechen nicht dagegen) und per DLL-Hijacking zur Ausführung zu bringen, können Angreifer über ose.exe administrative Berechtigungen erhalten.

Anmerkung: DLL-Hijacking ist ein passiver Angriff, der aktive Teil ist hier das Programm OSE[00000].exe, das über ein Dutzend DLLs aus %TEMP% lädt.

Programmierfehler als don't längst bekannt

Kein Rocket-Science, das ist alles längst bekannt. Stefan Kanthak schreibt dazu:

%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

Das Ganze wurde bereits unzählige Male für Entwickler in der Liste der Top-Software-Fehler, die man wirklich vermeiden sollte, dokumentiert. Hier drei Fundstellen, die Stefan Kanthak mir gemailt hat:

CWE-377: Insecure Temporary File
CWE-379: Creation of Temporary File in Directory with Incorrect Permissions
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

Was ist DLL-Hijacking?

Die Erkenntnis: (Fast) alle Programme (übrigens auch Sachen wie z.B. Microsofts Sicherheitsupdates), die in %TEMP% Dateien entpacken und zur Ausführung bringen, sind für DLL-Hijacking anfällig. Und noch schlimmer: Die zum Schließen der Schwachstelle bereitgestellten Fixes sind selbst für DLL-Hijacking anfällig! Stefan Kanthak schreibt dazu:

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\

Angreifer brauchen nur bestimmte DLLs in den Ordner %TEMP% zu speichern. Gibt es Abhängigkeiten zu diesen DLLs in der ose.exe, lädt 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ür seine Zwecke nutzen.

Es gibt in Windows einen Mechanismus der 'Known good DLLs', der das Problem vermeiden könnte – das Ganze ist hier seit 2004 beschrieben. Scheint aber wohl nicht genutzt zu werden. Angemerkt sei aber, dass die "Known DLLs" primär eine Maßnahme zur Performance-Steigerung sind. Sekundär bieten sie aber eine (schwache) Sicherheitsmaßnahme, die aber seit Windows 2000 durch "DLL redirection" (<filename>.exe.local) und seit
Windows XP durch "application manifests" TRIVIAL ausgehebelt werden
kann. Details zu letzterem sind im Beitrag DLL Minesweeper durch Stefan Kanthak demonstriert (siehe den optionalen Schritt 3).

DLL-Hijacking ist bestens dokumentiert

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üssten.

CWE-426: Untrusted Search Path
CWE-427: Uncontrolled Search Path Element
CAPEC-471: DLL Search Order Hijacking

Nun könnte man noch argumentieren, dass Microsofts Leute möglicherweise nicht auf fremden Webseiten mitlesen. Aber das Unternehmen veröffentlicht ja eigenen Anleitungen für Programmieranfänger:

Dynamic-Link Library Security
Microsoft Security Advisory 2269637
Secure loading of libraries to prevent DLL preloading attacks
Load Library Safely

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ären.

Ein Proof of Concept

Stefan Kanthak hat ein Proof of Concept, wie sich diese Schwachstelle ausnutzen lässt, veröffentlicht. Hierzu schreibt er folgendes.

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%!

Die Historie der Schwachstelle

Interessant ist die Konversation zwischen Stefan Kanthak und Microsoft, der diese Schwachstelle an das Unternehmen gemeldet hat. Ich poste das mal ohne Kommentar:

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

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öffentlichung. Hier der Auszug aus einer Mail von Stefan Kanthak an das MSRC-Team:

> Was there a specific timeline upon which you were planning to disclose?

It's overdue!
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.

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.

JFTR: DLL hijacking (more precise: DLL search order hijacking) is VERY WELL-known and WELL-documented for more that 20 years.

      I hope that you expressed your congratulations to David LeBlanc
      today: his blog post has its 10th (in words: TENTH) anniversary!
      <see>

> 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.
Yes, under the condition that you report progress!

> 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.
OK. I take your word.

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.

Die mit '>' beginnenden Zeilen sind die Antwort des Microsoft Mitarbeiters aus dem MSRC-Team. Und hier der Auszug aus der nächsten Antwort-Mail, in der Microsoft verspricht, die Kuh vom Eis zu holen:

> Thanks for your patience up to this point and for coordinating with
> 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.

> We're also planning on updating documentation describing actions users
> will have to take as far as updating installation media, as appropriate.

OK, I REALLY appreciate that.

> 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?

I'll delay the disclosure until after the May patch tuesday.

Der Bitte, die Veröffentlichung bis zum Mai-Patchday (8.5.2018) zu verschieben, wurde also stattgegeben.

Versuch, im Oktober 2017 zu fixen

Gemäß Historie gab es bereits im Oktober 2017 den Versuch Microsofts, diese Schwachstelle in ose.exe zu schließen. Das ging aber in die Hose, wie diese Antwort von Stefan Kanthak auf die Rückmeldung des MSRC-Teams belegt.

>>>> Hi Travis/MSRC,
>>>>
>>>> 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>
<https://download.microsoft.com/download/E/E/4/EE4720B6-04E0-42F8-8078-7A1FFABD9DB6/ose2013-kb3172524-fullfile-x86-glb.exe>
<https://download.microsoft.com/download/2/7/3/2737636B-EEE4-4BBB-8378-ED08894298C6/ose2010-kb2553338-fullfile-x86-glb.exe>
>>>>      and save them in your "Downloads" directory;
>>>>
>>>>   2. fetch
>>>>      <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>
>>>>      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

Das ging daneben, wie Stefan Kanthak gegenüber den Microsoft-Leuten demonstriert. Ich habe an dieser Stelle nur Auszüge 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 – aber Microsoft hatte ja einen weiteren Schuss frei. Im Mai 2018 sollte es soweit sein (Aussage des MSRC-Teams).

Microsoft veröffentlicht ein Office-Defense in Depth Update

Im Advisory ADV170017 (ADV170017 | Microsoft Office Defense in Depth Update) vom 8. Mai 2018 geht Microsoft auf das Problem ein und veröffentlicht ein Sicherheitsupdate für Office 2010 bis Office 2016, welches die Schwachstelle ausbügeln soll.

Beachtet, dass die Fixes nur noch Microsoft Office 2010, 2013 und 2016 beinhalten – im Oktober 2017 wäre zumindest noch Microsoft Office 2007 dabei gewesen.

Ist die Lücke nun geschlossen?

Man könnte nun ja sagen: Was lange braucht, wird endlich gut – obwohl ich bei Microsoft da mittlerweile so meine Zweifel habe. Das wurde auch mal wieder prompt bestätigt, denn Stefan Kanthak schickte mir vor einigen Tagen eine zweite Mail mit folgendem Inhalt:

Hi Travis,

> Hello Stefan,
>
> As defense-in-depth updates were released as expected yesterday,

Dump them, they are STILL vulnerable!
Please reread my mail from 2017-10-20:

| On a fully patched Windows 7 SP1, the "fixed" OSE.EXE installed by
| 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.

The ose.exe published yesterday still show this behaviour!
Please read <https://skanthak.homepage.t-online.de/minesweeper.html>
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.

> and the associated advisory was updated, I'm going to go ahead and
> close this case.

Why? The vulnerability still persists!
I recommend to fire the whole Office Setup team including their managers
and QA, then hire some COMPETENT developers instead!

> If you have any questions or concerns, please feel free to respond
> to this email and I'd be happy to reopen the case.
>
> Thanks again for working with us!

Not amused!
Stefan Kanthak

PS: I miss my name in the acknowledgements for the May 2018 patchday!

Tja, mir fehlen irgendwie die Worte. Man hat irgend etwas gestopft, was in dieses Internet geschrieben und ist der Meinung, man könne den Fall nun bei Microsoft schließen. Aber Stefan Kanthak weist darauf hin, dass sich im Grunde nix geändert hat, denn die neu ausgelieferte ose.exe hat weiterhin Modulabhängigkeiten und wird im Ordner %Temp% abgelegte Dateien wie Version.dll, WinHTTP.dll und WebIO.dll ungeprüft nachladen.

Das Allerletzte

Der Ratschlag von Stefan Kanthak lautet, dass Office-Setup-Team samt der Qualitätssicherung 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ße in Grün zu finden ist (ich habe nur noch nicht drüber gebloggt). Wenn man also diesen Ratschlag umsetzt, lichten sich wohl die Entwicklerhallen in Redmond – und mit neuen Entwicklern, die die Sicherheitsthematik drauf haben, gibt es dann das Problem, dass die das Zeugs nicht verstehen, was ihre Vorgänger verbrochen haben. Mag da nicht im Detail aus dem Nähkästchen '30 Jahre Erfahrung mit Microsoft' plaudern – aber mir sind solche Fälle unter die Augen gekommen.

Anmerkung: Stefan Kanthak schrieb mir dazu 'Solche (auf CAPEC und CWE seit Jahren dokumentierte) Anfängerfehler macht nicht nur Microsoft, sondern alle Firmen und Organisationen, die ausführbare 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, …