Microsoft Security Bulletin MS12-016 - Kritisch

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• In einem webbasierten Angriffsszenario kann ein Angreifer eine Website mit einer Seite einrichten, die diese Sicherheitsanfälligkeit ausnutzt. Außerdem können manipulierte Websites und Websites, die von Endbenutzern bereitgestellte Inhalte oder Werbemitteilungen akzeptieren oder hosten, speziell gestaltete Inhalte enthalten, über die diese Sicherheitsanfälligkeit ausgenutzt werden kann. Ein Angreifer kann Endbenutzer jedoch nicht zum Besuch solcher Websites zwingen. Er muss den Benutzer zum Besuch dieser Website verleiten. Zu diesem Zweck wird der Benutzer meist dazu gebracht, in einer E-Mail oder einer Instant Messenger-Nachricht auf einen Link zur Website des Angreifers zu klicken.
• Internet Explorer unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 wird standardmäßig in einem eingeschränkten Modus verwendet, der als verstärkte Sicherheitskonfiguration bezeichnet wird. Dieser Modus verringert diese Sicherheitsanfälligkeit nur unter Windows Server 2008 und Windows Server 2008 R2 und nur in einem webbasierten Angriffsszenario. Weitere Informationen zur verstärkten Sicherheitskonfiguration von Internet Explorer finden Sie im Abschnitt „Häufig gestellte Fragen (FAQs)“.
• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der lokale Benutzer oder das Benutzerkonto von ASP.NET erlangen. Für Endbenutzer oder Konten, die mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.
• In einem Webhostingszenario muss ein Angreifer über die Berechtigung verfügen, willkürliche ASP.NET-Seiten auf eine Website hochzuladen, und ASP.NET muss auf diesem Webserver installiert sein. In der Standardkonfiguration kann ein anonymer Benutzer keinen Microsoft .NET-Code auf einen Internet Information Server (IIS) hochladen und ausführen.
• Standardmäßig wird ASP.NET-Anwendungen mit teilweiser Vertrauenswürdigkeit keine SocketPermission gewährt. Infolgedessen kann diese Sicherheitsanfälligkeit in einem serverseitigen Szenario nicht in ASP.NET-Anwendungen mit einer mittleren oder niedrigeren Vertrauensebene ausgenutzt werden, es sei denn, den Anwendungen wurde durch den Administrator explizit SocketPermission gewährt. Weitere Informationen zu ASP.NET-Vertrauensebenen finden Sie in dem MSDN-Artikel ASP.NET Vertrauensebenen und Richtliniendateien.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• Deaktivieren von XAML-Browseranwendungen in Internet Explorer

  Sie können sich vor dieser Sicherheitsanfälligkeit schützen, indem Sie die Einstellungen so ändern, dass vor der Ausführung von XAML-Browseranwendungen (XBAPs) eine Bestätigung verlangt wird. Sie können auch XAML-Browseranwendungen (XBAPs) in der Internetzone und lokalen Intranetzone folgendermaßen deaktivieren:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen.
  2. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für Loose XAML auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  3. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für XAML-Browseranwendungen auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  4. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für XPS-Dokumente auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  5. Klicken Sie auf der Registerkarte Sicherheit auf Stufe anpassen. Setzen Sie unter .NET Framework-basierende Komponenten die Option Ausführen von Komponenten, die nicht mit Authenticode signiert sind entweder auf Bestätigen oder auf Deaktivieren, und klicken Sie dann auf OK. Wiederholen Sie diese Schritte für Ausführen von Komponenten, die nicht mit Authenticode signiert sind, und klicken Sie dann auf OK.
  6. Klicken Sie auf Lokales Intranet und dann auf Stufe anpassen. Wiederholen Sie die Schritte 3 und 4. Wenn Sie dazu aufgefordert werden, die Änderung dieser Einstellungen zu bestätigen, klicken Sie auf Ja. Klicken Sie auf OK, um zu Internet Explorer zurückzukehren.

  Auswirkung der Problemumgehung: Microsoft .NET-Code wird in Internet Explorer nicht oder nur mit Eingabeaufforderung ausgeführt. Durch das Deaktivieren von Microsoft .NET-Anwendungen und -Komponenten in den Internet- und lokalen Intranetzonen funktionieren einige Websites eventuell nicht ordnungsgemäß. Wenn Sie nach der Änderung dieser Einstellung Probleme mit einer Website haben und überzeugt sind, dass die Website sicher ist, können Sie diese zur Liste vertrauenswürdiger Sites hinzufügen. Dann funktioniert die Website einwandfrei.

  Fügen Sie der Zone der vertrauenswürdigen Sites von Internet Explorer vertrauenswürdige Sites hinzu.

  Nachdem Sie Internet Explorer so konfiguriert haben, dass vor der Ausführung von ActiveX-Steuerelementen und Active Scripting in der Internetzone und lokalen Intranetzone eine Bestätigung verlangt wird, können Sie der Zone der vertrauenswürdigen Sites von Internet Explorer vertrauenswürdige Sites hinzufügen. Auf diese Weise können Sie vertrauenswürdige Websites wie zuvor weiterverwenden und sich gleichzeitig vor diesem Angriff von nicht vertrauenswürdigen Sites schützen. Microsoft empfiehlt, der Zone der vertrauenswürdigen Sites nur Sites hinzufügen, denen Sie vertrauen.

  Führen Sie dazu die folgenden Schritte durch:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen und dann auf die Registerkarte Sicherheit.
  2. Klicken Sie im Feld Wählen Sie eine Zone von Webinhalten aus, um die Sicherheitseinstellungen für diese Zone anzugeben auf Vertrauenswürdige Sites und anschließend auf Sites.
  3. Wenn Sie Sites hinzufügen möchten, die keinen verschlüsselten Kanal benötigen, deaktivieren Sie das Kontrollkästchen Für Sites dieser Zone ist eine Serverüberprüfung (https:) erforderlich.
  4. Geben Sie im Feld Diese Website der Zone hinzufügen die URL einer Site ein, der Sie vertrauen, und klicken Sie dann auf Hinzufügen.
  5. Wiederholen Sie diese Schritte für jede Site, die Sie der Zone hinzufügen möchten.
  6. Klicken Sie zweimal auf OK, um die Änderungen zu übernehmen und zu Internet Explorer zurückzukehren.

  Hinweis: Fügen Sie alle Sites hinzu, bei denen Sie sicher sind, dass diese auf Ihrem Computer keine Schaden verursachenden Aktionen durchführen. Erwägen Sie insbesondere das Hinzufügen der Sites *.windowsupdate.microsoft.com und *.update.microsoft.com. Auf diesen Sites erhalten Sie das Update. Für die Installation des Updates ist ein ActiveX-Steuerelement erforderlich.

  So machen Sie die Problemumgehung rückgängig. Führen Sie die folgenden Schritte durch:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen.
  2. Klicken Sie auf der Registerkarte Sicherheit auf Alle Zonen auf Standardstufe zurücksetzen und dann auf OK.
• Deaktivieren Sie vorübergehend das Microsoft Silverlight-ActiveX-Steuerelement in Internet Explorer (Methode 1)

  Sie können sich gegen diese Sicherheitsanfälligkeiten schützen, indem Sie vorübergehend Versuche verhindern, das Silverlight-ActiveX-Steuerelement in Internet Explorer zu instanziieren. Dazu wird das Kill Bit für das Steuerelement gesetzt.

  Warnung: Eine fehlerhafte Verwendung des Registrierungs-Editors kann unter Umständen ernste Probleme verursachen, die eine erneute Installation des Betriebssystems erfordern können. Microsoft übernimmt keine Garantie dafür, dass Sie Probleme lösen können, die auf das fehlerhafte Verwenden des Registrierungs-Editors zurückzuführen sind. Verwenden Sie den Registrierungs-Editor auf eigenes Risiko.

  Es wird empfohlen, eine Sicherungskopie der Registrierung zu erstellen, bevor Sie sie bearbeiten.

  Verwenden Sie den folgenden Text, um eine REG-Datei zu erstellen, die vorübergehend alle Versuche verhindert, eine Instanz des Silverlight-ActiveX-Steuerelements für Flash Player in Internet Explorer zu erstellen. Sie können den folgenden Text kopieren, diesen in einen Texteditor wie Editor einfügen, und die Datei dann mit der Dateinamenerweiterung „.reg“ speichern. Führen Sie die REG-Datei auf dem anfälligen Client aus.

  Windows Registrierungs-Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{DFEAF541-F3E1-4C24-ACAC-99C30715084A}]
"Compatibility Flags"=dword:00000400

  Schließen Sie Internet Explorer und öffnen Sie ihn erneut, damit die Änderungen wirksam werden.

  Weitere Informationen dazu, wie Sie verhindern, dass ein Steuerelement in Internet Explorer ausgeführt wird, finden Sie im Microsoft Knowledge Base-Artikel 240797. Führen Sie die folgenden Schritte aus und erstellen Sie einen Wert für Kompatibilitätskennzeichen in der Registrierung, um zu verhindern, dass das Silverlight-ActiveX-Steuerelement in Internet Explorer ausgeführt wird.

  Auswirkung der Problemumgehung: Anwendungen und Websites, die das Microsoft Silverlight-ActiveX-Steuerelement erfordern, funktionieren u. U. nicht mehr richtig. Wenn Sie diese Problemumgehung implementieren, wirkt sie sich auf alle Silverlight-ActiveX-Steuerelement aus, die Sie auf Ihrem System installiert haben.

  So machen Sie die Problemumgehung rückgängig. Entfernen Sie die Registrierungsschlüssel, die hinzugefügt wurden, um vorübergehend Versuche zu verhindern, das Silverlight-ActiveX-Steuerelement in Internet Explorer zu instanziieren.

• Deaktivieren Sie vorübergehend das Microsoft Silverlight-ActiveX-Steuerelement in Firefox oder Chrome

  Führen Sie die folgenden Schritte aus, um den Registrierungsschlüssel zu ändern und Microsoft Silverlight zu deaktivieren:

  Hinweis: Eine fehlerhafte Verwendung des Registrierungs-Editors kann unter Umständen ernste Probleme verursachen, die eine erneute Installation des Betriebssystems erfordern können. Microsoft kann nicht gewährleisten, dass Probleme, die sich aus der fehlerhaften Verwendung des Registrierungs-Editors ergeben, behoben werden können. Verwenden Sie den Registrierungs-Editor auf eigenes Risiko. Weitere Informationen zum Bearbeiten der Registrierung finden Sie im Hilfethema Ändern von Schlüsseln und Werten im Registrierungs-Editor (Regedit.exe) oder in den Hilfethemen über das Hinzufügen und das Löschen von Informationen in der Registrierung und im Hilfethema Bearbeiten der Registrierungsdaten in Regedt32.exe.

  • Verwenden der interaktiven Methode
    1. Klicken Sie auf Start und dann auf Ausführen, geben Sie im Feld Öffnen den Befehl Regedit ein, und klicken Sie anschließend auf OK.
    2. Suchen Sie den folgenden Registrierungsunterschlüssel, und klicken Sie darauf:

       HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0

    3. Klicken Sie mit der rechten Maustaste auf @Microsoft.com/NpCtrl,version=1.0, und wählen Sie Exportieren aus. Speichern Sie die Datei auf der Festplatte.
    4. Löschen Sie den gesamten Schlüssel @Microsoft.com/NpCtrl,version=1.0.
    5. Beenden Sie den Registrierungs-Editor.
  • Verwenden einer Registrierungsdatei
    1. Erstellen Sie eine Sicherungskopie der Registrierungsschlüssel. Eine Sicherungskopie kann durch ein verwaltetes Bereitstellungsskript mit dem folgenden Befehl erstellt werden:

       Regedit.exe /e SL_backup.reg HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0

    2. Speichern Sie Folgendes in einer Datei mit der Erweiterung .REG (z. B. Disable_Silverlight.reg):

       Windows Registrierungs-Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0]

    3. Führen Sie mit folgendem Befehl das in Schritt 2 auf dem Zielcomputer erstellte obige Registrierungsskript aus:

       Regedit /s Disable_Silverlight.reg

  So machen Sie die Problemumgehung rückgängig.

  • Verwenden der interaktiven Methode
    1. Klicken Sie auf Start und dann auf Ausführen, geben Sie im Feld Öffnen den Befehl Regedit ein, und klicken Sie anschließend auf OK.
    2. Klicken Sie im Menü Datei auf Importieren.
    3. Wählen Sie in Suchen in das Laufwerk, den Ordner oder den Netzwerkcomputer aus, auf dem sich die zuvor exportierte Datei befindet.
    4. Wählen Sie den richtigen Dateinamen aus, und klicken Sie anschließend auf Öffnen.
  • Verwenden eines verwalteten Bereitstellungsskripts

    Stellen Sie mit dem folgenden Befehl die Datei wieder her, von der in Schritt 1 „Verwenden einer Registrierungsdatei“ oben eine Sicherungskopie erstellt wurde:

    Regedit /s SL_backup.reg

Worin genau besteht diese Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit kann Remotecodeausführung ermöglichen. Nutzt ein Angreifer diese Sicherheitsanfälligkeit erfolgreich aus, kann er die vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit tritt in Erscheinung, wenn Microsoft .NET Framework und Microsoft Silverlight nicht verwaltete Objekte falsch verwenden.

Was ist Microsoft Silverlight? 
Microsoft Silverlight ist eine browserübergreifende, plattformübergreifende Implementierung von Microsoft .NET Framework zum Erstellen von Mediendarstellungen und reichhaltigen interaktiven Anwendungen für das Internet. Weitere Informationen finden Sie auf der offiziellen Website von Microsoft Silverlight.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
In einem webbasierten Szenario kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, die gleichen Berechtigungen erlangen wie der angemeldete Benutzer. Wenn ein Benutzer mit administrativen Benutzerberechtigungen angemeldet ist, kann ein Angreifer vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

Im Webhostingszenario kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, die gleichen Berechtigungen erlangen wie das Dienstkonto, das der Anwendungspoolidentität des Anwendungspools zugeordnet ist, in dem eine Microsoft .NET-Anwendung ausgeführt wird. In Abhängigkeit von der Isolationskonfiguration des Anwendungspools und den Berechtigungen, die dem Dienstkonto gewährt wurden, kann ein Angreifer die Kontrolle über andere Anwendungspools auf dem Webserver oder die vollständige Kontrolle über das betroffene System erlangen. Weitere Informationen zu Anwendungspoolidentitäten und zur Konfiguration finden Sie im TechNet-Artikel Konfigurieren der Anwendungspoolidentität.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Es gibt drei mögliche Angriffsszenarien für die Ausnutzung dieser Sicherheitsanfälligkeit: ein webbasiertes Szenario, ein Webhostingszenario und ein Windows .NET-Anwendungsszenario, bei dem die Einschränkungen der Codezugriffssicherheit (CAS) umgangen werden. Diese Szenarien werden folgendermaßen beschrieben:

• Webbasiertes Angriffsszenario
  Ein Angreifer kann eine speziell gestaltete Website hosten, die eine speziell gestaltete XBAP (XAML-Browseranwendung) enthält, mit der diese Sicherheitsanfälligkeit ausgenutzt werden kann, und dann einen Benutzer dazu verleiten, die Website anzuzeigen. Der Angreifer kann auch beeinträchtigte Websites und Websites nutzen, die von Benutzern bereitgestellte Inhalte oder Anzeigen akzeptieren oder hosten. Diese Websites können speziell gestaltete Inhalte enthalten, mit denen diese Sicherheitsanfälligkeit ausgenutzt werden kann. Ein Angreifer kann Endbenutzer jedoch nicht zum Besuch solcher Websites zwingen. Er muss den Benutzer zu einem Besuch dieser Webseite verleiten. Zu diesem Zweck wird der Benutzer normalerweise dazu gebracht, in einer E-Mail oder einer Instant Messenger-Anfrage auf einen Link zur Website des Angreifers zu klicken. Es besteht ebenfalls die Möglichkeit, speziell gestalteten Webinhalt mithilfe von Bannerwerbungen anzuzeigen oder Webinhalt auf andere Weise an betroffene Systeme zu übermitteln.
• Webhosting-Angriffsszenario
  Wenn eine Webhostingumgebung Benutzern ermöglicht, benutzerdefinierte ASP.NET-Anwendungen hochzuladen, kann ein Angreifer eine schädliche ASP.NET-Anwendung hochladen, die diese Sicherheitsanfälligkeit verwendet, um aus der Sandbox auszubrechen, mit der ASP.NET-Code am Durchführen schädlicher Aktionen auf dem Serversystem gehindert wird.
• Windows .NET-Anwendungsszenario
  Diese Sicherheitsanfälligkeit kann auch von Windows .NET-Anwendungen verwendet werden, um Einschränkungen durch die Codezugriffssicherheit (CAS) zu umgehen.

Was ist eine XAML-Browseranwendung (XBAP)? 
Eine XAML-Browseranwendung (XBAP) kombiniert Funktionen sowohl einer Webanwendung als auch einer Rich Client-Anwendung. Ebenso wie Webanwendungen können XBAPs auf einem Webserver veröffentlicht und in Internet Explorer gestartet werden. Ebenso wie Rich Client-Anwendungen können XBAPs die Möglichkeiten von Windows Presentation Foundation (WPF) nutzen. Weitere Informationen zu XBAPs finden Sie in dem MSDN-Artikel XAML-Browseranwendungen von Windows Presentation Foundation im Überblick.

Was sind Einschränkungen der Codezugriffssicherheit (CAS) für .NET Framework? 
.NET Framework stellt einen Sicherheitsmechanismus namens Codezugriffssicherheit bereit, der Computersysteme vor schädlichem mobilem Code schützt, die Ausführung von Code aus unbekannten Quellen mit Schutz ermöglicht und verhindert, dass vertrauenswürdiger Code absichtlich oder zufällig die Sicherheit beeinträchtigt. Dank der Codezugriffssicherheit (CAS) kann die Vertrauenswürdigkeit von Code je nach Quelle und anderen Aspekten der Codeeigenschaften eingestuft werden. Die Codezugriffssicherheit setzt auch die unterschiedlichen Stufen der Vertrauenswürdigkeit von Code um, um die Menge an Code zu minimieren, der vollkommen vertrauenswürdig sein muss, um ausgeführt zu werden. Die Verwendung der Codezugriffssicherheit kann die Wahrscheinlichkeit verringern, dass Ihr Code von schädlichem oder fehlerhaftem Code missbraucht wird. Weitere Informationen zu CAS finden Sie im MSDN-Artikel Codezugriffssicherheit.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Die drei Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, Systeme, die das Webhostingszenario verwenden, und Systeme, die das Windows .NET-Anwendungsszenario verwenden.

• Webbasiertes Szenario
  Um diese Sicherheitsanfälligkeit erfolgreich ausnutzen zu können, muss ein Benutzer angemeldet sein und mit einem Webbrowser Websites besuchen, der XBAPs instanziieren kann. Für Systeme, auf denen häufig ein Webbrowser genutzt wird (z. B. Arbeitsstationen oder Terminalserver), besteht daher das größte Risiko. Bei Servern ist das Risiko größer, wenn Administratoren Benutzern ermöglichen, E-Mails auf Servern zu lesen und zu durchsuchen. Es wird jedoch dringend davon abgeraten, diese Erlaubnis zu erteilen.
• Webhostingszenario
  Webhostingsites, die Benutzern ermöglichen, benutzerdefinierte ASP.NET-Anwendungen hochzuladen, sind besonders gefährdet.
• Windows .NET-Anwendungen
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Ich führe Internet Explorer für Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 aus. Wird dadurch diese Sicherheitsanfälligkeit verringert? 
Ja. Internet Explorer unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 wird standardmäßig in einem eingeschränkten Modus verwendet, der als verstärkte Sicherheitskonfiguration bezeichnet wird. Die verstärkte Sicherheitskonfiguration von Internet Explorer besteht aus einer Gruppe vorkonfigurierter Internet Explorer-Einstellungen, durch die die Wahrscheinlichkeit verringert wird, dass ein Endbenutzer oder Administrator speziell gestaltete Webinhalte auf einen Server herunterlädt und dort ausführt. Dies ist ein schadensbegrenzender Faktor für Websites, die nicht zu den vertrauenswürdigen Sites von Internet Explorer hinzugefügt wurden.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie Microsoft .NET Framework und Microsoft Silverlight nicht verwaltete Objekte verwenden.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Nein. Microsoft hat Informationen zu dieser Sicherheitsanfälligkeit durch eine koordinierte Offenlegung der Sicherheitsanfälligkeit erhalten.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• In einem webbasierten Angriffsszenario kann ein Angreifer eine Website mit einer Seite einrichten, die diese Sicherheitsanfälligkeit ausnutzt. Außerdem können manipulierte Websites und Websites, die von Endbenutzern bereitgestellte Inhalte oder Werbemitteilungen akzeptieren oder hosten, speziell gestaltete Inhalte enthalten, über die diese Sicherheitsanfälligkeit ausgenutzt werden kann. Ein Angreifer kann Endbenutzer jedoch nicht zum Besuch solcher Websites zwingen. Er muss den Benutzer zum Besuch dieser Website verleiten. Zu diesem Zweck wird der Benutzer meist dazu gebracht, in einer E-Mail oder einer Instant Messenger-Nachricht auf einen Link zur Website des Angreifers zu klicken.
• Internet Explorer unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 wird standardmäßig in einem eingeschränkten Modus verwendet, der als verstärkte Sicherheitskonfiguration bezeichnet wird. Dieser Modus verringert diese Sicherheitsanfälligkeit nur unter Windows Server 2008 und Windows Server 2008 R2 und nur in einem webbasierten Angriffsszenario. Weitere Informationen zur verstärkten Sicherheitskonfiguration von Internet Explorer finden Sie im Abschnitt „Häufig gestellte Fragen (FAQs)“.
• In einem Webhostingszenario muss ein Angreifer über die Berechtigung verfügen, willkürliche ASP.NET-Seiten auf eine Website hochzuladen, und ASP.NET muss auf diesem Webserver installiert sein. In der Standardkonfiguration kann ein anonymer Benutzer keinen Microsoft .NET-Code auf einen Internet Information Server (IIS) hochladen und ausführen.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• Deaktivieren von XAML-Browseranwendungen in Internet Explorer

  Sie können sich vor dieser Sicherheitsanfälligkeit schützen, indem Sie die Einstellungen so ändern, dass vor der Ausführung von XAML-Browseranwendungen (XBAPs) eine Bestätigung verlangt wird. Sie können auch XAML-Browseranwendungen (XBAPs) in der Internetzone und lokalen Intranetzone folgendermaßen deaktivieren:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen.
  2. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für Loose XAML auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  3. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für XAML-Browseranwendungen auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  4. Klicken Sie auf die Registerkarte Sicherheit, dann auf Internet und auf Stufe anpassen. Klicken Sie unter Einstellungen für XPS-Dokumente auf Bestätigen oder Deaktivieren, und klicken Sie dann auf OK.
  5. Klicken Sie auf der Registerkarte Sicherheit auf Stufe anpassen. Setzen Sie unter .NET Framework-basierende Komponenten die Option Ausführen von Komponenten, die nicht mit Authenticode signiert sind entweder auf Bestätigen oder auf Deaktivieren, und klicken Sie dann auf OK. Wiederholen Sie diese Schritte für Ausführen von Komponenten, die nicht mit Authenticode signiert sind, und klicken Sie dann auf OK.
  6. Klicken Sie auf Lokales Intranet und dann auf Stufe anpassen. Wiederholen Sie die Schritte 3 und 4. Wenn Sie dazu aufgefordert werden, die Änderung dieser Einstellungen zu bestätigen, klicken Sie auf Ja. Klicken Sie auf OK, um zu Internet Explorer zurückzukehren.

  Auswirkung der Problemumgehung: Microsoft .NET-Code wird in Internet Explorer nicht oder nur mit Eingabeaufforderung ausgeführt. Durch das Deaktivieren von Microsoft .NET-Anwendungen und -Komponenten in den Internet- und lokalen Intranetzonen funktionieren einige Websites eventuell nicht ordnungsgemäß. Wenn Sie nach der Änderung dieser Einstellung Probleme mit einer Website haben und überzeugt sind, dass die Website sicher ist, können Sie diese zur Liste vertrauenswürdiger Sites hinzufügen. Dann funktioniert die Website einwandfrei.

  Fügen Sie der Zone der vertrauenswürdigen Sites von Internet Explorer vertrauenswürdige Sites hinzu.

  Nachdem Sie Internet Explorer so konfiguriert haben, dass vor der Ausführung von ActiveX-Steuerelementen und Active Scripting in der Internetzone und lokalen Intranetzone eine Bestätigung verlangt wird, können Sie der Zone der vertrauenswürdigen Sites von Internet Explorer vertrauenswürdige Sites hinzufügen. Auf diese Weise können Sie vertrauenswürdige Websites wie zuvor weiterverwenden und sich gleichzeitig vor diesem Angriff von nicht vertrauenswürdigen Sites schützen. Microsoft empfiehlt, der Zone der vertrauenswürdigen Sites nur Sites hinzufügen, denen Sie vertrauen.

  Führen Sie dazu die folgenden Schritte durch:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen und dann auf die Registerkarte Sicherheit.
  2. Klicken Sie im Feld Wählen Sie eine Zone von Webinhalten aus, um die Sicherheitseinstellungen für diese Zone anzugeben auf Vertrauenswürdige Sites und anschließend auf Sites.
  3. Wenn Sie Sites hinzufügen möchten, die keinen verschlüsselten Kanal benötigen, deaktivieren Sie das Kontrollkästchen Für Sites dieser Zone ist eine Serverüberprüfung (https:) erforderlich.
  4. Geben Sie im Feld Diese Website der Zone hinzufügen die URL einer Site ein, der Sie vertrauen, und klicken Sie dann auf Hinzufügen.
  5. Wiederholen Sie diese Schritte für jede Site, die Sie der Zone hinzufügen möchten.
  6. Klicken Sie zweimal auf OK, um die Änderungen zu übernehmen und zu Internet Explorer zurückzukehren.

  Hinweis: Fügen Sie alle Sites hinzu, bei denen Sie sicher sind, dass diese auf Ihrem Computer keine Schaden verursachenden Aktionen durchführen. Erwägen Sie insbesondere das Hinzufügen der Sites *.windowsupdate.microsoft.com und *.update.microsoft.com. Auf diesen Sites erhalten Sie das Update. Für die Installation des Updates ist ein ActiveX-Steuerelement erforderlich.

  So machen Sie die Problemumgehung rückgängig. Führen Sie die folgenden Schritte durch:

  1. Klicken Sie in Internet Explorer im Menü Extras auf Internetoptionen.
  2. Klicken Sie auf der Registerkarte Sicherheit auf Alle Zonen auf Standardstufe zurücksetzen und dann auf OK.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit kann Remotecodeausführung ermöglichen. Nutzt ein Angreifer diese Sicherheitsanfälligkeit erfolgreich aus, kann er die vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird verursacht, wenn .NET Framework beim Bearbeiten speziell gestalteter Eingaben eine Pufferlänge falsch berechnet.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
In einem webbasierten Szenario kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, die gleichen Berechtigungen erlangen wie der angemeldete Benutzer. Wenn ein Benutzer mit administrativen Benutzerberechtigungen angemeldet ist, kann ein Angreifer vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

Im Webhostingszenario kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, die gleichen Berechtigungen erlangen wie das Dienstkonto, das der Anwendungspoolidentität des Anwendungspools zugeordnet ist, in dem eine Microsoft .NET-Anwendung ausgeführt wird. In Abhängigkeit von der Isolationskonfiguration des Anwendungspools und den Berechtigungen, die dem Dienstkonto gewährt wurden, kann ein Angreifer die Kontrolle über andere Anwendungspools auf dem Webserver oder die vollständige Kontrolle über das betroffene System erlangen. Weitere Informationen zu Anwendungspoolidentitäten und zur Konfiguration finden Sie im TechNet-Artikel Konfigurieren der Anwendungspoolidentität.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Es gibt drei mögliche Angriffsszenarien für die Ausnutzung dieser Sicherheitsanfälligkeit: ein webbasiertes Szenario, ein Webhostingszenario und ein Windows .NET-Anwendungsszenario, bei dem die Einschränkungen der Codezugriffssicherheit (CAS) umgangen werden. Diese Szenarien werden folgendermaßen beschrieben:

• Webbasiertes Angriffsszenario
  Ein Angreifer kann eine speziell gestaltete Website hosten, die eine speziell gestaltete XBAP (XAML-Browseranwendung) enthält, mit der diese Sicherheitsanfälligkeit ausgenutzt werden kann, und dann einen Benutzer dazu verleiten, die Website anzuzeigen. Der Angreifer kann auch beeinträchtigte Websites und Websites nutzen, die von Benutzern bereitgestellte Inhalte oder Anzeigen akzeptieren oder hosten. Diese Websites können speziell gestaltete Inhalte enthalten, mit denen diese Sicherheitsanfälligkeit ausgenutzt werden kann. Ein Angreifer kann Endbenutzer jedoch nicht zum Besuch solcher Websites zwingen. Er muss den Benutzer zu einem Besuch dieser Webseite verleiten. Zu diesem Zweck wird der Benutzer normalerweise dazu gebracht, in einer E-Mail oder einer Instant Messenger-Anfrage auf einen Link zur Website des Angreifers zu klicken. Es besteht ebenfalls die Möglichkeit, speziell gestalteten Webinhalt mithilfe von Bannerwerbungen anzuzeigen oder Webinhalt auf andere Weise an betroffene Systeme zu übermitteln.
• Webhosting-Angriffsszenario
  Wenn eine Webhostingumgebung Benutzern ermöglicht, benutzerdefinierte ASP.NET-Anwendungen hochzuladen, kann ein Angreifer eine schädliche ASP.NET-Anwendung hochladen, die diese Sicherheitsanfälligkeit verwendet, um aus der Sandbox auszubrechen, mit der ASP.NET-Code am Durchführen schädlicher Aktionen auf dem Serversystem gehindert wird.
• Windows .NET-Anwendungsszenario
  Diese Sicherheitsanfälligkeit kann auch von Windows .NET-Anwendungen verwendet werden, um Einschränkungen durch die Codezugriffssicherheit (CAS) zu umgehen.

Was ist eine XAML-Browseranwendung (XBAP)? 
Eine XAML-Browseranwendung (XBAP) kombiniert Funktionen sowohl einer Webanwendung als auch einer Rich Client-Anwendung. Ebenso wie Webanwendungen können XBAPs auf einem Webserver veröffentlicht und in Internet Explorer gestartet werden. Ebenso wie Rich Client-Anwendungen können XBAPs die Möglichkeiten von Windows Presentation Foundation (WPF) nutzen. Weitere Informationen zu XBAPs finden Sie in dem MSDN-Artikel XAML-Browseranwendungen von Windows Presentation Foundation im Überblick.

Was sind Einschränkungen der Codezugriffssicherheit (CAS) für .NET Framework? 
.NET Framework stellt einen Sicherheitsmechanismus namens Codezugriffssicherheit bereit, der Computersysteme vor schädlichem mobilem Code schützt, die Ausführung von Code aus unbekannten Quellen mit Schutz ermöglicht und verhindert, dass vertrauenswürdiger Code absichtlich oder zufällig die Sicherheit beeinträchtigt. Dank der Codezugriffssicherheit (CAS) kann die Vertrauenswürdigkeit von Code je nach Quelle und anderen Aspekten der Codeeigenschaften eingestuft werden. Die Codezugriffssicherheit setzt auch die unterschiedlichen Stufen der Vertrauenswürdigkeit von Code um, um die Menge an Code zu minimieren, der vollkommen vertrauenswürdig sein muss, um ausgeführt zu werden. Die Verwendung der Codezugriffssicherheit kann die Wahrscheinlichkeit verringern, dass Ihr Code von schädlichem oder fehlerhaftem Code missbraucht wird. Weitere Informationen zu CAS finden Sie im MSDN-Artikel Codezugriffssicherheit.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Die drei Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, Systeme, die das Webhostingszenario verwenden, und Systeme, die das Windows .NET-Anwendungsszenario verwenden.

• Webbasiertes Szenario
  Um diese Sicherheitsanfälligkeit erfolgreich ausnutzen zu können, muss ein Benutzer angemeldet sein und mit einem Webbrowser Websites besuchen, der XBAPs instanziieren kann. Für Systeme, auf denen häufig ein Webbrowser genutzt wird (z. B. Arbeitsstationen oder Terminalserver), besteht daher das größte Risiko. Bei Servern ist das Risiko größer, wenn Administratoren Benutzern ermöglichen, E-Mails auf Servern zu lesen und zu durchsuchen. Es wird jedoch dringend davon abgeraten, diese Erlaubnis zu erteilen.
• Webhostingszenario
  Webhostingsites, die Benutzern ermöglichen, benutzerdefinierte ASP.NET-Anwendungen hochzuladen, sind besonders gefährdet.
• Windows .NET-Anwendungen
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Ich führe Internet Explorer für Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 aus. Wird dadurch diese Sicherheitsanfälligkeit verringert? 
Ja. Internet Explorer unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 wird standardmäßig in einem eingeschränkten Modus verwendet, der als verstärkte Sicherheitskonfiguration bezeichnet wird. Die verstärkte Sicherheitskonfiguration von Internet Explorer besteht aus einer Gruppe vorkonfigurierter Internet Explorer-Einstellungen, durch die die Wahrscheinlichkeit verringert wird, dass ein Endbenutzer oder Administrator speziell gestaltete Webinhalte auf einen Server herunterlädt und dort ausführt. Dies ist ein schadensbegrenzender Faktor für Websites, die nicht zu den vertrauenswürdigen Sites von Internet Explorer hinzugefügt wurden.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie Microsoft .NET Framework Pufferlängen berechnet.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Ja. Diese Sicherheitsanfälligkeit wurde veröffentlicht. Ihr wurde die Nummer für allgemeine Sicherheitsanfälligkeit CVE-2012-0015 zugewiesen.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Trägt die Installation dieses Sicherheitsupdates zum Schutz der Benutzer vor dem veröffentlichten Code bei, mit dem versucht wird, diese Sicherheitsanfälligkeit auszunutzen? 
Ja. Durch dieses Sicherheitsupdate wird die Sicherheitsanfälligkeit behoben, die mithilfe der veröffentlichten Codebeispiele für ein Angriffskonzept ausgenutzt werden kann. Der beseitigten Sicherheitsanfälligkeit wurde die Nummer für allgemeine Sicherheitsanfälligkeit CVE-2012-0015 zugewiesen.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Hinweis: Das Update für unterstützte Versionen von Windows XP Professional x64 Edition gilt auch für unterstützte Versionen von Windows Server 2003 x64 Edition.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Hinweis: Das Update für unterstützte Versionen von Windows Server 2003 x64 Edition gilt auch für unterstützte Versionen von Windows XP Professional x64 Edition.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.