Microsoft Security Bulletin MS12-074 - 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:

• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der lokale Endbenutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.
• Standardmäßig verhindern Internet Explorer 9 und Internet Explorer 10, dass XAML, welches von XBAPS verwendet wird, in der Internetzone ausgeführt wird.
• Standardmäßig sind Internet Explorer 6, Internet Explorer 7 und Internet Explorer 8 darauf konfiguriert, den Benutzer zu einer Bestätigung aufzufordern, bevor XAML ausgeführt wird, das von XBAPS in der Internetzone verwendet wird.

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 eingestellt haben, dass XAML-Browseranwendungen deaktiviert werden oder eine Bestätigung fordern, bevor Loose XAML, XAML-Browseranwendungen oder XPS-Dokumente in der „Internetzone“ und in der „Lokalen Intranetzone“ ausgeführt werden, können Sie der „Zone der vertrauenswürdigen Sites“ von Internet Explorer Sites hinzufügen, denen Sie vertrauen. 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 für eine lokale Erhöhung von Berechtigungen ausgenutzt werden.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird dadurch verursacht, dass .NET Framework die Berechtigungen von Objekten falsch überprüft, die Reflektion durchführen.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Wenn ein Angreifer diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann er vollständige Kontrolle über das betroffene System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Es gibt zwei mögliche Angriffsszenarien für die Ausnutzung dieser Sicherheitsanfälligkeit: ein webbasiertes Szenario 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.
• Windows .NET-Anwendungsszenario
  Diese Sicherheitsanfälligkeit kann auch von Windows .NET Framework-Anwendungen verwendet werden, um Einschränkungen durch die Codezugriffssicherheit (CAS) zu umgehen.

Was ist die CLR? 
In Microsoft .NET Framework wird eine Laufzeitumgebung namens Common Language Runtime (CLR) bereitgestellt, die den Code ausführt und Dienste bereitstellt, die den Entwicklungsprozess vereinfachen. Weitere Informationen zur CLR finden Sie unter Common Language Runtime – Übersicht.

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 beiden Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, und Systeme, die das Windows .NET Framework-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.
• Windows .NET-Anwendungen
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET Framework-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie .NET Framework die Berechtigungen von Objekten überprüft, die Reflektion durchführen.

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.

Für diese Sicherheitsanfälligkeit gibt es noch keine schadensbegrenzenden Faktoren.

Für diese Sicherheitsanfälligkeit gibt es bislang keine Problemumgehungen.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Dies ist eine Sicherheitsanfälligkeit, die sich auf die Offenlegung von Informationen bezieht.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird dadurch verursacht, wenn .NET Framework die Ausgabe einer Funktion nicht richtig bereinigt, die von teilweise vertrauenswürdigem Code aufgerufen wurde.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
In einem webbasierten Szenario kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, mithilfe von teilweise vertrauenswürdigem Code vertrauliche Informationen abrufen, die auf dem Zielsystem vorhanden sind und die normalerweise nur vollständig vertrauenswürdigem Code zugänglich wären.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Es gibt zwei mögliche Angriffsszenarien für die Ausnutzung dieser Sicherheitsanfälligkeit: ein webbasiertes Szenario 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.
• Windows .NET-Anwendungsszenario
  Diese Sicherheitsanfälligkeit kann auch von Windows .NET Framework-Anwendungen verwendet werden, um Einschränkungen durch die Codezugriffssicherheit (CAS) zu umgehen.

Was ist die CLR? 
In Microsoft .NET Framework wird eine Laufzeitumgebung namens Common Language Runtime (CLR) bereitgestellt, die den Code ausführt und Dienste bereitstellt, die den Entwicklungsprozess vereinfachen. Weitere Informationen zur CLR finden Sie unter Common Language Runtime – Übersicht.

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 beiden Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, und Systeme, die das Windows .NET Framework-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.
• Windows .NET-Anwendungen
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET Framework-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem Ausgaben auf Basis der Vertrauensebene des aufrufenden Codes richtig bereinigt werden.

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:

• Oft ist das Dateifreigabeprotokoll SMB (Server Message Block) in der Umkreisfirewall deaktiviert. Dadurch werden potenzielle Angriffsmethoden für diese Sicherheitsanfälligkeit eingeschränkt.
• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der angemeldete Benutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

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 des Ladens von Bibliotheken von WebDAV und Remotenetzwerkfreigaben

  Hinweis: Siehe Microsoft Knowledge Base-Artikel 2264107 zur Bereitstellung eines Problemumgehungstools, das Benutzern ermöglicht, das Laden von Bibliotheken von Remotenetzwerk- oder WebDAV-Freigaben zu deaktivieren. Dieses Tool kann so konfiguriert werden, dass das nicht sichere Laden pro Anwendung oder für das gesamte System nicht zulässig ist.

  Benutzer, die von ihrem Lieferanten über eine anfällige Anwendung informiert werden, können sich mit diesem Tool gegen Versuche schützen, dieses Problem auszunutzen.

  Hinweis: Siehe Microsoft Knowledge Base-Artikel 2264107 zur Verwendung der automatisierten Microsoft Fix it-Lösung, um den Registrierungsschlüssel bereitzustellen, der das Laden von Bibliotheken für SMB- und WebDAV-Freigaben blockiert. Beachten Sie, dass Sie für diese Fix it-Lösung zuerst das Problemumgehungstool installieren müssen, das auch im Microsoft Knowledge Base-Artikel 2264107 beschrieben wurde. Diese Fix it-Lösung stellt nur den Registrierungsschlüssel bereit und erfordert das Problemumgehungstool, um wirksam zu werden. Wir empfehlen Administratoren, den KB-Artikel sorgfältig zu lesen, bevor sie diese Fix it-Lösung bereitstellen.

• Deaktivieren des WebClient-Dienstes

  Durch das Deaktivieren des WebClient-Dienstes werden betroffene Systeme vor Versuchen geschützt, diese Sicherheitsanfälligkeit auszunutzen, indem die wahrscheinlichste Remoteangriffsmethode durch den Client-Dienst Web Distributed Authoring and Versioning (WebDAV) blockiert wird. Nachdem diese Problemumgehung angewendet wurde, können Remoteangreifer diese Sicherheitsanfälligkeit immer noch erfolgreich ausnutzen und bewirken, dass das System Programme ausführt, die sich auf dem Computer des Benutzers oder dem lokalen Netzwerk (LAN) befinden. Benutzer werden aber dazu aufgefordert, das willkürliche Öffnen von Programmen im Internet zu bestätigen.

  Gehen Sie wie folgt vor, um den WebClient-Dienst zu deaktivieren:

  1. Klicken Sie auf Start, dann auf Ausführen, geben Sie Services.msc ein, und klicken Sie anschließend auf OK.
  2. Klicken Sie mit der rechten Maustaste auf WebClient-Dienst und wählen Sie Eigenschaften aus.
  3. Ändern Sie den Starttyp in Deaktiviert. Wenn der Dienst ausgeführt wird, klicken Sie auf Beenden.
  4. Klicken Sie auf OK, und beenden Sie die Verwaltungsanwendung.

  Auswirkung der Problemumgehung. Wenn der WebClient-Dienst deaktiviert ist, werden Web Distributed Authoring and Versioning-Anforderungen (WebDAV) nicht übertragen. Außerdem werden keine Dienste gestartet, die explizit vom WebClient-Dienst abhängen, und im Systemprotokoll wird eine Fehlermeldung verzeichnet. Zum Beispiel kann vom Clientcomputer nicht auf WebDAV-Freigaben zugegriffen werden.

  So machen Sie die Problemumgehung rückgängig.

  Gehen Sie wie folgt vor, um den WebClient-Dienst wieder zu deaktivieren:

  1. Klicken Sie auf Start, dann auf Ausführen, geben Sie Services.msc ein, und klicken Sie anschließend auf OK.
  2. Klicken Sie mit der rechten Maustaste auf WebClient-Dienst und wählen Sie Eigenschaften aus.
  3. Ändern Sie den Starttyp in Automatisch. Wenn der Dienst nicht ausgeführt wird, klicken Sie auf Start.
  4. Klicken Sie auf OK, und beenden Sie die Verwaltungsanwendung.
• Blockieren der TCP-Ports 139 und 445 an der Firewall:

  Diese Ports werden dazu verwendet, eine Verbindung mit der betroffenen Komponente zu initiieren. Das Blockieren der TCP-Ports 139 und 445 an der Firewall schützt Systeme hinter dieser Firewall vor Angriffen, die diese Sicherheitsanfälligkeit auszunutzen versuchen. Microsoft empfiehlt das Blockieren der gesamten unerwünscht eingehenden Kommunikation aus dem Internet. So können Sie Angriffe verhindern, bei denen möglicherweise andere Ports verwendet werden. Weitere Informationen zu den Ports finden Sie im TechNet-Artikel TCP- und UDP-Portzuweisungen.

  Auswirkung der Problemumgehung. Mehrere Windows-Dienste verwenden die betroffenen Ports. Durch das Blockieren der Verbindung zu den Ports funktionieren verschiedene Anwendungen oder Dienste möglicherweise nicht mehr. Einige der möglicherweise betroffenen Anwendungen und Dienste werden im Folgenden aufgeführt.

  • Anwendungen, die SMB (CIFS) verwenden
  • Anwendungen, die Mailslots oder Named Pipes (RPC über SMB) verwenden
  • Server (Datei- und Druckerfreigabe)
  • Gruppenrichtlinie
  • Anmeldedienst
  • Distributed File System (DFS)
  • Terminal Server-Lizenzierung
  • Druckwarteschlange
  • Computerbrowser
  • Remote Procedure Call Locator
  • Faxdienst
  • Indexdienst
  • Leistungsprotokolle und Warnmeldungen
  • Systems Management Server
  • Lizenzprotokollierdienst

  So machen Sie die Problemumgehung rückgängig. Aufheben der Blockierung der TCP-Ports 139 und 445 an der Firewall. Weitere Informationen zu den Ports finden Sie unter TCP- und UDP-Portzuweisungen.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit kann Remotecodeausführung ermöglichen.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird dadurch verursacht, dass Entity Framework, eine .NET Framework Komponente, den für das Laden externer Bibliotheken verwendeten Pfad falsch einschränkt.

Was ist Entity Framework?  
Entity Framework ist ein Satz von Technologien in ADO.NET, der die Entwicklung datenorientierter Softwareanwendungen unterstützt. Weitere Informationen finden Sie im MSDN-Artikel Entity Framework: Übersicht.

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

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen?  
Ein Angreifer kann einen Benutzer dazu verleiten, eine gültige, mit ADO.NET erstellte .NET-Anwendung zu öffnen, die sich im selben Netzwerkverzeichnis befindet wie eine speziell gestaltete DLL-Datei (Dynamic Link Library). Dann kann die .NET-Anwendung versuchen, die DLL-Datei zu laden und den darin enthaltenen Code auszuführen.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Arbeitsstationen und Terminalserver sind am meisten gefährdet. Bei Servern ist das Risiko größer, wenn Administratoren Benutzern ermöglichen, sich bei Servern anzumelden und Programme auszuführen. Es wird jedoch dringend davon abgeraten, diese Erlaubnis zu erteilen.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie .NET Framework externe Bibliotheken lädt.

Steht diese Sicherheitsanfälligkeit in Zusammenhang mit der Microsoft-Sicherheitsempfehlung 2269637? 
Ja, diese Sicherheitsanfälligkeit steht in Zusammenhang mit der in der Microsoft-Sicherheitsempfehlung 2269637 beschriebenen Klasse von Sicherheitsanfälligkeiten, die sich darauf auswirken, wie Anwendungen externe Bibliotheken laden. Mit diesem Sicherheitsupdate wird eine besondere Instanz dieser Art von Sicherheitsanfälligkeit behoben.

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:

• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der lokale Endbenutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

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:

• Konfigurieren von Internet Explorer, WPAD nicht zu verwenden
  1. Klicken Sie auf Start, dann auf Systemsteuerung und anschließend auf Netzwerk und Internet, und klicken Sie dann auf Internetoptionen.
  2. Klicken Sie im Fenster Interneteigenschaften auf die Registerkarte Verbindungen und dann auf LAN Einstellungen.
  3. Deaktivieren Sie im Fenster Einstellungen für lokales Netzwerk (LAN) das Kontrollkästchen Automatische Suche der Einstellungen, und klicken Sie dann auf OK.

  Auswirkung der Problemumgehung. Web Proxy Auto-Discovery wird in Internet Explorer deaktiviert.

  So machen Sie die Problemumgehung rückgängig. Befolgen Sie die oben stehenden Schritt in umgekehrter Reihenfolge. Stellen Sie dabei sicher, dass Automatische Suche der Einstellungen im Fenster Einstellungen für lokales Netzwerk (LAN) aktiviert ist.

   

• Registrieren von WPAD

  Befolgen Sie die Schritte im Microsoft Knowledge Base-Artikel 934864, um WPAD zu registrieren.

  Auswirkung der Problemumgehung. WPAD wird von einem Administrator registriert, bevor ein Angreifer die Gelegenheit dazu erhält.

  So machen Sie die Problemumgehung rückgängig. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 934864.

   

• Verlassen Sie sich nicht auf die standardmäßigen Webproxyeinstellungen in Ihrer .NET- Anwendung

  Verlassen Sie sich nicht auf die standardmäßigen Proxyeinstellungen in .NET Framework, weder explizit durch die Eigenschaft „WebRequest.DefaultWebProxy“ noch implizit, indem Sie den Proxy (wie weiter unten angezeigt) in Ihrer .NET-Anwendung nicht festlegen. Standardmäßig wird diese Eigenschaft durch den Proxy oder die WPAD-Einstellungen in Internet Explorer festgelegt. Entwickler sollten den Webproxy in der Anwendung explizit wie folgt konfigurieren:

  IWebProxy proxy = new WebProxy("<IP_ADDRESSE>", <PORTNUMMER>);

  Wenn die Eigenschaft „DefaultWebProxy“ bereits in Ihrer .NET-Anwendung verwendet wird, stellen Sie sicher, dass der Name des gewünschten Proxys in der Datei „app.config“ hartkodiert ist.

  Dokumentation zu der Eigenschaft „WebRequest.DefaultWebProxy“ finden Sie unter Die Eigenschaft „WebRequest.DefaultWebProxy“.

  Hinweis: Dies erfordert das erneute Kompilieren und Bereitstellen der betroffenen Anwendungen.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit kann Remotecodeausführung ermöglichen.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird durch einen Mangel an Überprüfung verursacht, wenn .NET Framework die standardmäßigen Webproxyeinstellungen abruft und in der Proxy-Autokonfigurationsdatei JavaScript ausführt.

Ich führe Microsoft .NET Framework 4.5 unter Windows 8, Windows Server 2012 oder Windows RT aus, bin ich von diesem Problem betroffen?  
Nein, Endbenutzer, die Microsoft .NET Framework 4.5 unter Windows 8, Windows Server 2012 oder Windows RT ausführen, sind nicht von diesem Problem betroffen. Das kumulative Update (KB2756872) für die allgemeine Verfügbarkeit von Windows 8 Client und Windows Server 2012, das am 10. Oktober 2012 veröffentlicht wurde, enthält zusätzliche Tiefenverteidigungsänderungen. Endbenutzer, die dieses Update nicht bereits installiert haben, sind angehalten, dies als Tiefenverteidigungsmaßnahme durchzuführen. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 2745030 im Abschnitt „Weitere Informationen“. Downloadadressen und weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 2756872. Dieses Update enthält nicht sicherheitsbezogene Inhalte.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann 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.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen?  
Bei einem Man-in-the-Middle-Angriff kann ein Angreifer die Inhalte oder den Speicherort einer Proxy-Autokonfigurationsdatei (PAC) nachahmen und dann Code in die aktuell ausgeführte Anwendung einschleusen, wobei die Einschränkungen der Codezugriffssicherheit (CAS) umgangen werden.

Wenn der Angreifer Zugriff auf das lokale Netzwerk hat, kann er den Speicherort der PAC-Datei nachahmen, indem er ARP-Cache-Poisoning (Address Resolution Protocol) durchführt. Dabei werden Anfragen an die WPAD-Datei an eine IP-Adresse des Angreifers umgeleitet oder der NetBIOS-Namendienst (NBNS) nachgeahmt. Dort ahmt der Angreifer Antworten auf WPAD-Anfragen nach und leitet die Zielanwendung zu einer schädlichen PAC-Datei um, die auf einem Server des Angreifers gehostet wird.

Ausnutzung kann auftreten, wenn der Angreifer einen Benutzer dazu verleiten kann, eine Verbindung zu einem Server außerhalb der organisatorischen Grenze herzustellen. Folgende Szenarien können dies u. U. ermöglichen:

• DNS-Devolution: Eine Windows DNS-Client Funktion, mit der Windows DNS-Clients DNS-Abfragen für unqualifizierte Hostnamen mit einzelner Bezeichnung auflösen. Ein unbefugter Benutzer kann einen bestimmten Hostnamen außerhalb der Grenze der Organisation registrieren, der unabsichtlich von Clients kontaktiert werden kann, wenn diese falsch konfiguriert sind und bei dem Versuch, auf jenen Hostnamen zuzugreifen, die Devolution außerhalb der Grenze der Organisation durchführen.
• DNS-Spoofing: Ein Angreifer kann Sicherheitsanfälligkeiten im Windows DNS (Domain Name System) ausnutzen, was Spoofing ermöglicht. Diese Angriffe können einem Remoteangreifer ermöglichen, für Internet bestimmten Netzwerkverkehr auf sein eigenes System umzuleiten.

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.

Was ist Web Proxy Auto-Discovery (WPAD)?  
Die Web Proxy Auto-Discovery (WPAD)-Funktion befähigt Webclients, Proxyeinstellungen ohne Benutzereingriff automatisch zu erkennen. Die WPAD-Funktion stellt den Hostnamen „wpad“ dem vollqualifizierten Domänennamen voran und entfernt so lange Unterdomänen, bis es einen WPAD-Server findet, der zum Domänennamen passt. Weitere Informationen finden Sie unter WinHTTP AutoProxy Support.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Die beiden Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, und Systeme, die das Windows .NET Framework-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.
• Windows .NET-Anwendungsszenario
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET Framework-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem Microsoft.JScript in System.Net aktualisiert wird und eingeschränkt wird, wie .NET Framework JavaScript ausführt, das in einer WPAD-Konfigurationsdatei enthalten ist. Das Update ändert außerdem, wie WPAD mithilfe von WinHTTP an Stelle von Microsoft.JScript verarbeitet wird. Diese Änderung, wenn auch unwahrscheinlich, kann einige Kompatibilitätsprobleme in Umgebungen verursachen, die über nicht standardisierte Proxy-Autokonfigurationsumgebungen verfügen. Weitere Informationen zu dieser Änderung finden Sie im Microsoft Knowledge Base-Artikel 2745030 in dem Abschnitt „Weitere Informationen“.

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:

• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der lokale Endbenutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.
• Standardmäßig verhindern Internet Explorer 9 und Internet Explorer 10, dass XAML, welches von XBAPS verwendet wird, in der Internetzone ausgeführt wird.
• Standardmäßig sind Internet Explorer 6, Internet Explorer 7 und Internet Explorer 8 darauf konfiguriert, den Benutzer zu einer Bestätigung aufzufordern, bevor XAML ausgeführt wird, das von XBAPS in der Internetzone verwendet wird.

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 eingestellt haben, dass XAML-Browseranwendungen deaktiviert werden oder eine Bestätigung fordern, bevor Loose XAML, XAML-Browseranwendungen oder XPS-Dokumente in der „Internetzone“ und in der „Lokalen Intranetzone“ ausgeführt werden, können Sie der „Zone der vertrauenswürdigen Sites“ von Internet Explorer Sites hinzufügen, denen Sie vertrauen. 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 für eine lokale Erhöhung von Berechtigungen ausgenutzt werden.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird dadurch verursacht, dass .NET Framework die Berechtigungen von Objekten falsch überprüft, die an Reflektion beteiligt sind.

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.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Es gibt zwei mögliche Angriffsszenarien für die Ausnutzung dieser Sicherheitsanfälligkeit: ein webbasiertes Szenario 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.
• Windows .NET-Anwendungsszenario
  Diese Sicherheitsanfälligkeit kann auch von Windows .NET Framework-Anwendungen verwendet werden, um Einschränkungen durch die Codezugriffssicherheit (CAS) zu umgehen.

Was ist die WPF? 
Microsoft .NET Framework stellt einer Laufzeitumgebung namens Windows Presentation Foundation (WPF) bereit. Das ist ein Darstellungssystem zum Erstellen von Windows-Clientanwendungen. Weitere Informationen zu WPF finden Sie unter Einführung in WPF.

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 beiden Systemarten, die durch diese Sicherheitsanfälligkeit gefährdet sind, werden folgendermaßen beschrieben: Systeme, die das webbasierte Szenario verwenden, und Systeme, die das Windows .NET Framework-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.
• Windows .NET-Anwendungen
  Arbeitsstationen und Server, die nicht vertrauenswürdige Windows .NET Framework-Anwendungen ausführen, sind ebenfalls von dieser Sicherheitsanfälligkeit betroffen.

Was bewirkt das Update? 
Das Update behebt die Sicherheitsanfälligkeit, indem korrigiert wird, wie .NET Framework Code im Speicher optimiert.

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.

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.

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.