Dienstag, 24. August 2010
2264107 - Empfohlenes Update zur Steuerung des Ladeverhaltens von DLL-Dateien durch Anwendungen unter Windows XP - 24.08.10 [Update]
Kurzbeschreibung:
Optionales, aber empfohlenes Update, welches Administratoren die Steuerung des Ladeverhaltens von (externen) DLL-Dateien beim Start einer Anwendung unter Windows XP SP3 ermöglichen soll, um damit mögliche (auch sicherheitsrelevante) Probleme zu umgehen. Siehe Security Advisory (Sicherheitsempfehlung) 2269637 (englisch bzw. deutsch) sowie MSKB-Artikel KB2264107 und KB2389418. Weitere Hintergründe finden sich Einträgen des MSRC-Blog sowie Security Research & Defense-Blog von Microsoft, des unabhängigen Internet Storm Center sowie Rapid 7 Security Blog.
Aktuell: ja
direkter Download - wird bislang nicht über Windows Update angeboten.
Ergänzt:
Sicherheitsupdate KB956572 (MS09-012)
Enthält:
mrxdav.sys (5.1.2600.6007 - 30.06.2010)
ntdll.dll (5.1.2600.6007 - 30.06.2010)
Anmerkungen:
Zur Durchführung der nach der Installation dieses Updates möglichen Steuerung des Ladeverhaltens von DLL-Dateien von Anwendungen, ist ein manueller Eingriff in die Registry erforderlich. Dabei lässt sich das Ladeverhalten sowohl global für alle Anwendungen steuern, als auch für jede einzelne Anwendung individuell. Dies gilt auch für Anwendunge, die über WebDAV oder SMB aufgerufen werden. Details hierzu siehe MSKB-Artikel KB2264107. Zur Vereinfachung des erforderlichen Registry-Eingriffs, biete ich eine MSAdvisory226937_KB2264107.zip (2 KB) zum Download an. Bitte lesen Sie nach dem Entpacken der Datei vor der Ausführung der darin befindlichen MS-Advisory_226937_after_KB2264107.reg, welche den Registry-Wert CWDIllegalInDllSearch auf 0xFFFFFFFF setzt, die ebenfalls enthaltene liesmich_readme.txt. [Update, 01.09.2010, 05:45] Zwischenzeitlich stellt Microsoft über den MSKB-Artikel KB2264107 eine halbautomatische "Fix it"-Lösung bereit, welche den Registry-Wert CWDIllegalInDllSearch auf 2 setzt und somit bei lokal installierten Anwendungen das Suchen nach DLL-Dateien auf WebDAV bzw. SMB-Netzwerkfreigaben verhindern soll. Es handelt sich also um die zweitsicherste Variante. Diese "Fix it"-Lösung setzt ebenso wie die auf dieser kleinen Site angebotene MSAdvisory226937_KB2264107.zip voraus, dass das zugehörige Update KB2264107 bereits installiert wurde. zeigen beide Maßnahmen keinerlei Wirkung. Gleichzeitig teilt Microsoft in einem weiteren Artikel im MSRC-Blog u.a. mit, dass Microsoft für eigene Anwendungen, die für die Sicherheitslücke anfällig sind, an Sicherheitsupdates arbeitet. Ferner gibt es ebenfalls einen weiteren Eintrag im Security Research & Defense-Blog von Microsoft, in dem auf praktische Auswirkungen der Lücke (aus Microsoft-Sicht) eingegangen wird. [/ Update]
Optionales, aber empfohlenes Update, welches Administratoren die Steuerung des Ladeverhaltens von (externen) DLL-Dateien beim Start einer Anwendung unter Windows XP SP3 ermöglichen soll, um damit mögliche (auch sicherheitsrelevante) Probleme zu umgehen. Siehe Security Advisory (Sicherheitsempfehlung) 2269637 (englisch bzw. deutsch) sowie MSKB-Artikel KB2264107 und KB2389418. Weitere Hintergründe finden sich Einträgen des MSRC-Blog sowie Security Research & Defense-Blog von Microsoft, des unabhängigen Internet Storm Center sowie Rapid 7 Security Blog.
Aktuell: ja
direkter Download - wird bislang nicht über Windows Update angeboten.
Ergänzt:
Sicherheitsupdate KB956572 (MS09-012)
Enthält:
mrxdav.sys (5.1.2600.6007 - 30.06.2010)
ntdll.dll (5.1.2600.6007 - 30.06.2010)
Anmerkungen:
Zur Durchführung der nach der Installation dieses Updates möglichen Steuerung des Ladeverhaltens von DLL-Dateien von Anwendungen, ist ein manueller Eingriff in die Registry erforderlich. Dabei lässt sich das Ladeverhalten sowohl global für alle Anwendungen steuern, als auch für jede einzelne Anwendung individuell. Dies gilt auch für Anwendunge, die über WebDAV oder SMB aufgerufen werden. Details hierzu siehe MSKB-Artikel KB2264107. Zur Vereinfachung des erforderlichen Registry-Eingriffs, biete ich eine MSAdvisory226937_KB2264107.zip (2 KB) zum Download an. Bitte lesen Sie nach dem Entpacken der Datei vor der Ausführung der darin befindlichen MS-Advisory_226937_after_KB2264107.reg, welche den Registry-Wert CWDIllegalInDllSearch auf 0xFFFFFFFF setzt, die ebenfalls enthaltene liesmich_readme.txt. [Update, 01.09.2010, 05:45] Zwischenzeitlich stellt Microsoft über den MSKB-Artikel KB2264107 eine halbautomatische "Fix it"-Lösung bereit, welche den Registry-Wert CWDIllegalInDllSearch auf 2 setzt und somit bei lokal installierten Anwendungen das Suchen nach DLL-Dateien auf WebDAV bzw. SMB-Netzwerkfreigaben verhindern soll. Es handelt sich also um die zweitsicherste Variante. Diese "Fix it"-Lösung setzt ebenso wie die auf dieser kleinen Site angebotene MSAdvisory226937_KB2264107.zip voraus, dass das zugehörige Update KB2264107 bereits installiert wurde. zeigen beide Maßnahmen keinerlei Wirkung. Gleichzeitig teilt Microsoft in einem weiteren Artikel im MSRC-Blog u.a. mit, dass Microsoft für eigene Anwendungen, die für die Sicherheitslücke anfällig sind, an Sicherheitsupdates arbeitet. Ferner gibt es ebenfalls einen weiteren Eintrag im Security Research & Defense-Blog von Microsoft, in dem auf praktische Auswirkungen der Lücke (aus Microsoft-Sicht) eingegangen wird. [/ Update]
Dieses Update war bereits am 13. Juli 2010 kurzzeitig über das DownloadCenter von Microsoft verfügbar, ehe es wenige Tage/Stunden später aus nach wie vor unbekannten Gründen von Microsoft zurückgezogen wurde. Das jetzt erneut veröffentlichte Update entspricht dem kurzzeitig zurückgezogenen. Der Übersichtlichkeit halber, wurde ein neuer Artikel für die Neuveröffentlichung des Updates erstellt.
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Manchmal frage ich mich, ob es ein eigenes Team bei Microsoft dafür gibt, Beschreibungen für Sicherheitslücken, Workarounds und sicherheitsrelevante Registry-Einträge so bürokratisch und verschwurbelt zu formulieren, daß selbst ein fortgeschrittener Benutzer Mühe hat zu verstehen, worum es geht. Bislang bin ich mit hinreichend großem Aufwand immer noch halbwegs mitgekomen (hoffe ich), aber jetzt, bei dem KB-Artikel 2264107, steige ich aus.
Hat jemand Lust, mit mir Textexegese zu betreiben, um die eigentlich recht simple und nicht ganz unwichtige Frage zu beantworten: Welchen globalen Registry-Eintrag (d.h. in CCS\Session Manager, nicht anwendungsspezifisch) muß ich setzen, damit der beschriebene Angriffsvektor nie, bei keinem Szenario, zum Tragen kommt?
- 1? Damit wird zwar beim Starten lokal installierter Anwendungen ("Szenario 1") das Nachladen von DLLs aus WebDAV-Ordnern geblockt, aber nicht aus UNC-Pfaden.
- 2? Damit wird beim Starten lokal installierter Anwendungen ("Szenario 1") das Nachladen aus WebDAV-Ordnern und aus UNC-Pfaden geblockt, aber beim Starten der Anwendung aus einem UNC-Pfad ("Szenario 2") wird das Nachladen von DLLs aus UNC-Pfaden explizit erlaubt. Was zwei Folgefragen aufwirft: (a) Welche #$@*§ Logik steckt eigentlich hinter den verschiedenen Werten? (b) Ist ein Angriffsszenario denkbar, bei dem man eine Anwendung aus einem UNC-Pfad startet, ohne es zu merken?
- Und über Szenario 3 will ich erst gar nicht nachdenken, sonst krieg ich endgültig einen Knoten im Hirn...
Hat jemand Lust, mit mir Textexegese zu betreiben, um die eigentlich recht simple und nicht ganz unwichtige Frage zu beantworten: Welchen globalen Registry-Eintrag (d.h. in CCS\Session Manager, nicht anwendungsspezifisch) muß ich setzen, damit der beschriebene Angriffsvektor nie, bei keinem Szenario, zum Tragen kommt?
- 1? Damit wird zwar beim Starten lokal installierter Anwendungen ("Szenario 1") das Nachladen von DLLs aus WebDAV-Ordnern geblockt, aber nicht aus UNC-Pfaden.
- 2? Damit wird beim Starten lokal installierter Anwendungen ("Szenario 1") das Nachladen aus WebDAV-Ordnern und aus UNC-Pfaden geblockt, aber beim Starten der Anwendung aus einem UNC-Pfad ("Szenario 2") wird das Nachladen von DLLs aus UNC-Pfaden explizit erlaubt. Was zwei Folgefragen aufwirft: (a) Welche #$@*§ Logik steckt eigentlich hinter den verschiedenen Werten? (b) Ist ein Angriffsszenario denkbar, bei dem man eine Anwendung aus einem UNC-Pfad startet, ohne es zu merken?
- Und über Szenario 3 will ich erst gar nicht nachdenken, sonst krieg ich endgültig einen Knoten im Hirn...
Moin,
ja, die können schon was, zeigen es gelegentlich aber nicht
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
CWDIllegalInDllSearch = 0xFFFFFFFF
Es könnte sich aber für manche Anwendung als Problem herausstellen, DLL nicht aus dem "eigenen" Verzeichnis laden zu können. Für die kommt dann ein passender Inhalt für CWDIllegalInDllSearch in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
in Frage.
So zumindest mein Verständnis, auch von
"Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future." aus dem S&D-Blog.
Bye,
Freudi
ja, die können schon was, zeigen es gelegentlich aber nicht
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
CWDIllegalInDllSearch = 0xFFFFFFFF
Es könnte sich aber für manche Anwendung als Problem herausstellen, DLL nicht aus dem "eigenen" Verzeichnis laden zu können. Für die kommt dann ein passender Inhalt für CWDIllegalInDllSearch in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
in Frage.
So zumindest mein Verständnis, auch von
"Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future." aus dem S&D-Blog.
Bye,
Freudi
Danke für Deine Antwort ... vor dem "großen Hammer" FFFFFFFF hatte ich Respekt, aber das ist wohl wirklich die einzige sichere Methode. ("Sicher" auch im Hinblick auf eventuelle Ungenauigkeiten im KB-Artikel, die möglicherweise irgendwann mal korrigiert werden. Ich könnte mir nämlich vorstellen, daß die Werte 1 und 2 entgegen der derzeitigen MS-Beschreibung nicht exklusiv zu verstehen sind, sondern eigentlich eine Bitmaske bezeichnen, so daß 01 (1) + 10 (2) = 11 (3) auch ein erlaubter und sinnvoller Wert wäre. Vielleicht.)
Bis jetzt (Neustart schon passiert) funktioniert alles wie gewohnt. Dabei vertraue ich darauf, daß das "'eigene' Verzeichnis" der Anwendung, wie Du schreibst, von dem Registry-Wert gar nicht betroffen ist; das wäre nämlich nach meinem Verständnis in der Regel "The directory from which the application loaded", also das Installationsverzeichnis (Nr. 1 in der DLL-Suchreihenfolge laut KB-Artikel) und nicht das Arbeitsverzeichnis (CWD), das durch FFFFFFFF generell ausgeschlossen wird (wäre ansonsten Nr. 5 in der DLL-Suchreihenfolge).
Bis jetzt (Neustart schon passiert) funktioniert alles wie gewohnt. Dabei vertraue ich darauf, daß das "'eigene' Verzeichnis" der Anwendung, wie Du schreibst, von dem Registry-Wert gar nicht betroffen ist; das wäre nämlich nach meinem Verständnis in der Regel "The directory from which the application loaded", also das Installationsverzeichnis (Nr. 1 in der DLL-Suchreihenfolge laut KB-Artikel) und nicht das Arbeitsverzeichnis (CWD), das durch FFFFFFFF generell ausgeschlossen wird (wäre ansonsten Nr. 5 in der DLL-Suchreihenfolge).
Moin,
ja, Du hast recht, ich habe mich unpräzise/missverständlch ausgedrückt. Das Problem ist das (versuchte) Laden von DLL aus dem aktuellen Arbeitsverzeichnis, nicht das Installationsverzeichnis der Anwendung. Pardon.
Bye,
Freudi
ja, Du hast recht, ich habe mich unpräzise/missverständlch ausgedrückt. Das Problem ist das (versuchte) Laden von DLL aus dem aktuellen Arbeitsverzeichnis, nicht das Installationsverzeichnis der Anwendung. Pardon.
Bye,
Freudi
Wir haben hier das Update getestet und folgendes Problem festgestellt.
Bei einer Access/VBA Anwendung auf einer Netzwerkfreigabe wird eine externe DLL geladen. Diese wurde bis anhin nur gefunden, wenn das Arbeitsverzeichnis (CWD) entsprechend gesetzt wurde oder die DLL auf alle Client kopiert wird.
Nach dem setzen von
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
CWDIllegalInDllSearch = 0xFFFFFFFF
wird die DLL nicht mehr geladen.
Es durch zusätzliches setzen von
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MsAccess.exe
CWDIllegalInDllSearch = 0
Funktioniert es wieder.
Wir haben nicht herausgefunden, wie man sonst in VBA den vollständigen DLL-Pfad angeben kann.
Als Vorsicht mit VBA und DLL Aufrufen.
Bei einer Access/VBA Anwendung auf einer Netzwerkfreigabe wird eine externe DLL geladen. Diese wurde bis anhin nur gefunden, wenn das Arbeitsverzeichnis (CWD) entsprechend gesetzt wurde oder die DLL auf alle Client kopiert wird.
Nach dem setzen von
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
CWDIllegalInDllSearch = 0xFFFFFFFF
wird die DLL nicht mehr geladen.
Es durch zusätzliches setzen von
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MsAccess.exe
CWDIllegalInDllSearch = 0
Funktioniert es wieder.
Wir haben nicht herausgefunden, wie man sonst in VBA den vollständigen DLL-Pfad angeben kann.
Als Vorsicht mit VBA und DLL Aufrufen.
Wir haben nun auch das erste Microsoftprogramm, dass bei systemweiter Aktivierung eine Fehlermeldung anzeigt.
Outlook 2002 kann nicht mehr auf das Adressbuch zugreifen.
Abhilfe schafft:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Outlook.exe]
"CWDIllegalInDllSearch"=dword:00000001
Es funktioniert mit den Werten 0, 1, 2
Outlook 2002 kann nicht mehr auf das Adressbuch zugreifen.
Abhilfe schafft:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Outlook.exe]
"CWDIllegalInDllSearch"=dword:00000001
Es funktioniert mit den Werten 0, 1, 2
Moin,
siehe auch http://isc.sans.edu/diary.html?storyid=9445#comment wenn man das Ganze direkt im Path bewerkstelligen und keine Ausnahme definieren will.
Bye,
Freudi
siehe auch http://isc.sans.edu/diary.html?storyid=9445#comment wenn man das Ganze direkt im Path bewerkstelligen und keine Ausnahme definieren will.
Bye,
Freudi
Die Korrigiererei, die ich oben befürchtet hatte, geht schon los. Derzeit hat der KB-Artikel die Version 3.0, und das sind nicht nur kosmetische Änderungen. Soweit ich sehe, ist in Version 2.0 im wesentlichen der Name des Registry-Eintrags in den Tabellen korrigiert worden, dort stand ursprünglich "CWDIllegalInDllSearchValue", was natürlich Blödsinn ist und außerhalb der Tabellen auch korrekt angegeben wurde (CWDIllegalInDllSearch, ohne "Value").
Wer statt 0xFFFFFFFF den Wert 2 benutzt, ist gut beraten, nochmal in den KB-Artikel zu schauen. Folgendes wurde geändert:
- Szenario 1 ("The application is started from a local folder"): Klarstellung, daß die mit dem Wert 2 geblockten "remote folder" nicht nur UNC-Pfade sind, wie ich ursprünglich vermutet hatte, sondern UNC-Pfade und WebDAV-Ordner.
- Szenario 2 ("The application is started from a remote folder", womit diesmal aber offenbar wirklich nur UNC-Pfade gemeint sind, da WebDAV-Ordner in Szenario 3 behandelt werden):
Wert 2 bisher: "Allows DLL Load from the current working directory if the current working directory is set to a remote folder. Note that DLLs that are loaded from a WebDAV share are blocked if the CWD is set to a WebDAV share."
Wert 2 neu: "Allows DLL Load from the current working directory if the current working directory is set to a remote folder (such as a WebDAV or UNC location)."
Ich würde nicht ausschließen wollen, daß noch weitere Änderungen kommen, daher wie gesagt: Sicher geht man auch in dieser Hinsicht nur mit 0xFFFFFFFF.
Wer statt 0xFFFFFFFF den Wert 2 benutzt, ist gut beraten, nochmal in den KB-Artikel zu schauen. Folgendes wurde geändert:
- Szenario 1 ("The application is started from a local folder"): Klarstellung, daß die mit dem Wert 2 geblockten "remote folder" nicht nur UNC-Pfade sind, wie ich ursprünglich vermutet hatte, sondern UNC-Pfade und WebDAV-Ordner.
- Szenario 2 ("The application is started from a remote folder", womit diesmal aber offenbar wirklich nur UNC-Pfade gemeint sind, da WebDAV-Ordner in Szenario 3 behandelt werden):
Wert 2 bisher: "Allows DLL Load from the current working directory if the current working directory is set to a remote folder. Note that DLLs that are loaded from a WebDAV share are blocked if the CWD is set to a WebDAV share."
Wert 2 neu: "Allows DLL Load from the current working directory if the current working directory is set to a remote folder (such as a WebDAV or UNC location)."
Ich würde nicht ausschließen wollen, daß noch weitere Änderungen kommen, daher wie gesagt: Sicher geht man auch in dieser Hinsicht nur mit 0xFFFFFFFF.
Nunja, eigentlich sind es "nur" Klarstellungen, so z.B. auch der zuvor im KB-Artikel fehlende Hinweis, dass es sich um einen DWORD-Wert handelt. 0xFFFFFFFF bleibt in jedem Fall für ONU die sicherere Variante, die anderen Werte sind "lediglich" für -ähm- "Netzwerker" von Interesse. Was allerdings IMHO das gröbere Problem darstellen dürfte (und vermutlich auch zumindest mit ein Grund, weshalb das Update nicht via WU/MU/AU verteilt und mit entsprechdendem Registry-Key ausgeliefert wird), dürfte die Erstellung von Ausnahmen für widerspenstige Anwendungen sein. Für noch von MS unterstützte Programme und deren Versionen, dürfte es in nicht allzu ferner Zukunft eine Reihe von Updates hageln - oder die Begrenzung wird "nebenbei" mit anderen Problembehebungen/Sicherheitsupdates für dieselben verteilt werden. Wer da am Ende noch durchsteigen soll, ist mir schleierhaft.
Bye,
Freudi
Bye,
Freudi
Link zur angebotenen MSAdvisory226937_KB2264107.zip hinzugefügt.
Hi Freudi,
kann ich denn die Änderung auch wieder rückgängig machen falls es da zu Problemen kommen sollte?
Überschreibt
[quote]Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"CWDIllegalInDllSearch"=dword:00000002[/quote]
die vorherige Version 0xFFFFFFFF? Oder muß der Erste Eintrag erst in der Reg gelöscht werden?
Bin da nicht so bewandert.
Danke!
kann ich denn die Änderung auch wieder rückgängig machen falls es da zu Problemen kommen sollte?
Überschreibt
[quote]Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"CWDIllegalInDllSearch"=dword:00000002[/quote]
die vorherige Version 0xFFFFFFFF? Oder muß der Erste Eintrag erst in der Reg gelöscht werden?
Bin da nicht so bewandert.
Danke!
Moin Robert,
ja und ja. Welche Anwendung macht denn ein Deinem Fall Probleme, so dass Du über eine Reduzierung der Sicherheitsmaßnahmen nachdenkst?
Man kann auch über andere Registry-Schlüssel eine Ausnahme für diese Anwendung erstellen bzw. den "Path" der Anwendung so zurechtbiegen, dass die von der Anwendung "vermisste" DLL-Datei gefunden wird.
Bye,
Freudi
ja und ja. Welche Anwendung macht denn ein Deinem Fall Probleme, so dass Du über eine Reduzierung der Sicherheitsmaßnahmen nachdenkst?
Man kann auch über andere Registry-Schlüssel eine Ausnahme für diese Anwendung erstellen bzw. den "Path" der Anwendung so zurechtbiegen, dass die von der Anwendung "vermisste" DLL-Datei gefunden wird.
Bye,
Freudi
Danke für die schnelle Reaktion.
Alles läuft wunderbar hier bei mir nach der manuellen Änderung der Registrierung und der Einstellung 0xFFFFFFFF. Ich habe keine Probleme. Nur für den Fall der Fälle hatte ich gefragt falls ein Programm Probleme machen sollte.
Alles läuft wunderbar hier bei mir nach der manuellen Änderung der Registrierung und der Einstellung 0xFFFFFFFF. Ich habe keine Probleme. Nur für den Fall der Fälle hatte ich gefragt falls ein Programm Probleme machen sollte.
Ok, es würde mich dann allerdings durchaus auch interessieren, falls und wenn ja, mit welcher Anwendung es zu Problemen kommt.
Bye,
Freudi
Bye,
Freudi
Mach ich gerne.
Nach Installation der MS-Advisory_226937_after_KB2264107.reg,funktionierteAvast Antivirus Free Update nicht mehr.Alles rückgängig gemacht und Fix it drauf.Jetzt läufts wieder.
Moin,
hast Du dich an Avast gewandt? Sie sollten dieses Problem durch ein Update beheben. Neben der zweitbesten Möglichkeit, über das "Fix it"-Tool für alle Anwendungen die nur zweithöchste Sicherheitsstufe zu wählen, gäbe es noch die, die Sicherheitsstufe generell auf hoch zu lassen (also weiterhin den Wert auf "0xFFFFFF" zu belassen anstatt "2" wie im "Fix it"-Tool), für den Avast "Updater" (ich weiß nicht, wie die EXE heißt) eine Ausnahme über einen anderen Registry-Schlüssel und Wert zu definieren:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Name_der_EXE.exe
CWDIllegalInDllSearch = 2
Bye,
Freudi
hast Du dich an Avast gewandt? Sie sollten dieses Problem durch ein Update beheben. Neben der zweitbesten Möglichkeit, über das "Fix it"-Tool für alle Anwendungen die nur zweithöchste Sicherheitsstufe zu wählen, gäbe es noch die, die Sicherheitsstufe generell auf hoch zu lassen (also weiterhin den Wert auf "0xFFFFFF" zu belassen anstatt "2" wie im "Fix it"-Tool), für den Avast "Updater" (ich weiß nicht, wie die EXE heißt) eine Ausnahme über einen anderen Registry-Schlüssel und Wert zu definieren:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Name_der_EXE.exe
CWDIllegalInDllSearch = 2
Bye,
Freudi
Das kann ich nicht bestätigen. Hier laufen auf etlichen Rechnern die verschiedensten AV Lösungen und keine hat bisher ein Problem gemacht nach dem einspielen der "0xFFFFFF" Lösung.
Hallo Ottmar,
mein Altershobby (85)ist mein Computer....fühle mich aber noch nicht in der Lage einen neuen Schlüssel in die Registry einzufügen......Nach Installation der MS-Advisory_226937_after_KB2264107.reg,funktionierte
auch bei mir Avast Antivirus Free Update nicht mehr....nun erlaube ich mir die höfliche Anfrage, ob Du evtl.bereit wärest,mir zu helfen und
den von Dir vorgeschlagenen zusätzlichen Schlüssel
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Name_der_EXE.exe
CWDIllegalInDllSearch = 2" einfügungsbereit möglichst bald zuzuschicken.....wofür ich Dir sehr dankbar
wäre
))
der Name der EXE ist "ashUpd.exe"....meine e-mail-Adr.
ist [entfernt zur Spamvermeidung, Freudi]
beste Grüße,
Horst
mein Altershobby (85)ist mein Computer....fühle mich aber noch nicht in der Lage einen neuen Schlüssel in die Registry einzufügen......Nach Installation der MS-Advisory_226937_after_KB2264107.reg,funktionierte
auch bei mir Avast Antivirus Free Update nicht mehr....nun erlaube ich mir die höfliche Anfrage, ob Du evtl.bereit wärest,mir zu helfen und
den von Dir vorgeschlagenen zusätzlichen Schlüssel
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Name_der_EXE.exe
CWDIllegalInDllSearch = 2" einfügungsbereit möglichst bald zuzuschicken.....wofür ich Dir sehr dankbar
wäre
))der Name der EXE ist "ashUpd.exe"....meine e-mail-Adr.
ist [entfernt zur Spamvermeidung, Freudi]
beste Grüße,
Horst
Hallo Horst,
nach den mir voliegenden Informationen, sollte das Problem in Avast mit dem Update auf die Version 5.0.677 behoben sein, das am 07.09.2010 von Avast veröffentlicht wurde. Siehe http://www.avast.com/release-history ("Secunia Advisory SA41109") und http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3126
Welche Version ist denn auf Deinem Rechner installiert?
Falls es nicht die aktuelle Version 5.0.677 sein sollte, kannst Du Dir zum Updaten auf diese Version die "MS-Advisory226937_Ausnahme_ashUpd.zip" herunterladen:
http://patch-info.de/Downloads/Windows/MSAdvisory226937_Ausnahme_ashUpd.zip
Nach dem Auspacken der ZIP-Datei, findest Du zwei REG-Dateien. Die "MSAdvisory226937_Ausnahme_ashUpd.reg" setzt nach dem Importieren in die Registry die Ausnahme für die ashUpd.exe auf "2". Nachdem das Udpate auf die aktuelle Avast AV-Version erfolgt ist, solltest Du diese Ausnahme mit der "MSAdvisory226937_Ausnahme_ashUpd_löschen.reg" wieder entfernen.
Bye,
Freudi
P.S.: Ich habe die von Dir im Kommentar angegebene E-Mail-Adresse entfernt, um möglichen Spam an diese Adresse zu vermeiden.
nach den mir voliegenden Informationen, sollte das Problem in Avast mit dem Update auf die Version 5.0.677 behoben sein, das am 07.09.2010 von Avast veröffentlicht wurde. Siehe http://www.avast.com/release-history ("Secunia Advisory SA41109") und http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3126
Welche Version ist denn auf Deinem Rechner installiert?
Falls es nicht die aktuelle Version 5.0.677 sein sollte, kannst Du Dir zum Updaten auf diese Version die "MS-Advisory226937_Ausnahme_ashUpd.zip" herunterladen:
http://patch-info.de/Downloads/Windows/MSAdvisory226937_Ausnahme_ashUpd.zip
Nach dem Auspacken der ZIP-Datei, findest Du zwei REG-Dateien. Die "MSAdvisory226937_Ausnahme_ashUpd.reg" setzt nach dem Importieren in die Registry die Ausnahme für die ashUpd.exe auf "2". Nachdem das Udpate auf die aktuelle Avast AV-Version erfolgt ist, solltest Du diese Ausnahme mit der "MSAdvisory226937_Ausnahme_ashUpd_löschen.reg" wieder entfernen.
Bye,
Freudi
P.S.: Ich habe die von Dir im Kommentar angegebene E-Mail-Adresse entfernt, um möglichen Spam an diese Adresse zu vermeiden.
Hallo Ottmar,
vielen Dank für Deine Hilfsbereitschaft und Deinen prompten Bescheid.....glücklicherweise konnte ich heute morgen feststellen, daß mein Avast-Update einwandfrei funktioniert und die aktuelle Version 5.0.677 ist.......gestern abends habe ich nicht auf die VersionsNr. geachtet und lediglich bemerkt,daß das Update manuel nicht funktionierte und gerade zuvor hatte ich KB2264107 + MS-Advisory 226937
installiert.......nach einem kurzen Durchblick Deiner Site und Kommentare habe ich mich mit meiner Bitte an Dich gewandt.....und nun war alles überflüssig....nochmals herzlichen Dank für Deine Bemühungen !!
Gruß
Horst
vielen Dank für Deine Hilfsbereitschaft und Deinen prompten Bescheid.....glücklicherweise konnte ich heute morgen feststellen, daß mein Avast-Update einwandfrei funktioniert und die aktuelle Version 5.0.677 ist.......gestern abends habe ich nicht auf die VersionsNr. geachtet und lediglich bemerkt,daß das Update manuel nicht funktionierte und gerade zuvor hatte ich KB2264107 + MS-Advisory 226937
installiert.......nach einem kurzen Durchblick Deiner Site und Kommentare habe ich mich mit meiner Bitte an Dich gewandt.....und nun war alles überflüssig....nochmals herzlichen Dank für Deine Bemühungen !!
Gruß
Horst
Hallo Ottmar,
nun muß ich Dich doch nochmals belästigen,weil ich leider
gerade feststellen mußte,daß die Installations-exe von OutPost7 nicht mehr funktioniert ...ebensowenig wie die
Deinstallation,und wahrscheinlich auch das Upgrade...das gleiche mit OutPost4...da bin ich mit meinen begrenzten Kenntnissen nun ziemlich hilflos.....gibt es da eine zuverlässige Lösung, oder muß ich ich evtl.
KB2264107 nebst Registerschlüssel löschen und warten bis da eine endgültige Lösung gefunden wird....wäre Dir sehr dankbar für einen raschen Bescheid.
Gruß
Horst
nun muß ich Dich doch nochmals belästigen,weil ich leider
gerade feststellen mußte,daß die Installations-exe von OutPost7 nicht mehr funktioniert ...ebensowenig wie die
Deinstallation,und wahrscheinlich auch das Upgrade...das gleiche mit OutPost4...da bin ich mit meinen begrenzten Kenntnissen nun ziemlich hilflos.....gibt es da eine zuverlässige Lösung, oder muß ich ich evtl.
KB2264107 nebst Registerschlüssel löschen und warten bis da eine endgültige Lösung gefunden wird....wäre Dir sehr dankbar für einen raschen Bescheid.
Gruß
Horst
Moin Horst,
Du meinst dieses Firewall-Simulationsprogramm von Agnitum? Falls ja, was sagt der Hersteller dazu? Gibt es ein Update von Agnitum? Was bedeutet "funktioniert nicht" konkret? Welche Fehlermeldungen gibt es?
Die Deinstallation des von KB2264107 ist in keinem Fall notwendig. Im Notfall würde das Entfernen/Editieren (auf "0" setzen")/Anlegen der bekannten Registry-Schlüssel bzw. -Werte helfen - wenn denn wirklich ein Zusammenhang mit CWDIllegalInDllSearch überhaupt besteht.
Die Frage, weshalb Du Dich nicht auf die zuverlässig vor unerwünschten Zugriffen von außen schützenden Windows-Firewall verlässt, stelle ich besser nicht. Notwendig ist die Installation einer Personal Firewall Software (von welchem Hersteller auch immer) jedenfalls nicht.
Bye,
Freudi
Du meinst dieses Firewall-Simulationsprogramm von Agnitum? Falls ja, was sagt der Hersteller dazu? Gibt es ein Update von Agnitum? Was bedeutet "funktioniert nicht" konkret? Welche Fehlermeldungen gibt es?
Die Deinstallation des von KB2264107 ist in keinem Fall notwendig. Im Notfall würde das Entfernen/Editieren (auf "0" setzen")/Anlegen der bekannten Registry-Schlüssel bzw. -Werte helfen - wenn denn wirklich ein Zusammenhang mit CWDIllegalInDllSearch überhaupt besteht.
Die Frage, weshalb Du Dich nicht auf die zuverlässig vor unerwünschten Zugriffen von außen schützenden Windows-Firewall verlässt, stelle ich besser nicht. Notwendig ist die Installation einer Personal Firewall Software (von welchem Hersteller auch immer) jedenfalls nicht.
Bye,
Freudi
Hallo Ottmar,
ja,es handelt sich um die Agnitum-Firewall-OutPost7...ich arbeite schon immer damit und möchte nicht wechseln .....Im OutPost-Support-Forum finde ich nur einen in etwa passenden Hinweis....(hab aber leider nicht genügend engl.Sprachkenntnisse) wie folgt:
"Re: Unable to update or uninstall Outpost Firewall
For the benefit of anyone else who may have fallen into the same trap, I found the solution to this one.
I'd recently installed the Microsoft KB 2264107 update to provide protection for the DLL loading vulnerability, and had set the registry key to the highest protection level. Either part of Outpost itself or the installer must rely on loading DLLs from unusual paths because temporarily setting this key to 0 allowed the installer to work.
Even then the upgrade didn't install cleanly; access to the update server was blocked and I was left with what appeared to be a bunch of legacy settings from version 6 that couldn't be changed from within the new version 7 interface. This may or may not be directly related to the earlier problems but, either way, an uninstall and reinstall with a fresh configuration file seems to have done the trick."
Den Beweis dafür,daß KB2264107+ CWDIllegalInDllSearch der Grund dafür ist, sehe ich darin,daß die OutPost-Exen funktionieren,nachdem ich ein früheres Image bei welchem der Patch noch nicht installiert war auf eine separate Partition kopiert hatte...und dort funktionierte alles.
Du sagst:"
Im Notfall würde das Entfernen/Editieren (auf "0" setzen")/Anlegen der bekannten Registry-Schlüssel bzw. -Werte helfen......
und so wäre ich sehr dankbar,wenn Du mir sagen würdest, wie und was ich da genau zu tun habe,weil meine Kenntnisse damit noch überfordert sind.
Gruß,
Horst
P.S. leider sehe ich keine Möglichkeit, Dir auf diesem Weg die beiden shortCuts (Fehleranzeigen) mit
zu übersenden.
ja,es handelt sich um die Agnitum-Firewall-OutPost7...ich arbeite schon immer damit und möchte nicht wechseln .....Im OutPost-Support-Forum finde ich nur einen in etwa passenden Hinweis....(hab aber leider nicht genügend engl.Sprachkenntnisse) wie folgt:
"Re: Unable to update or uninstall Outpost Firewall
For the benefit of anyone else who may have fallen into the same trap, I found the solution to this one.
I'd recently installed the Microsoft KB 2264107 update to provide protection for the DLL loading vulnerability, and had set the registry key to the highest protection level. Either part of Outpost itself or the installer must rely on loading DLLs from unusual paths because temporarily setting this key to 0 allowed the installer to work.
Even then the upgrade didn't install cleanly; access to the update server was blocked and I was left with what appeared to be a bunch of legacy settings from version 6 that couldn't be changed from within the new version 7 interface. This may or may not be directly related to the earlier problems but, either way, an uninstall and reinstall with a fresh configuration file seems to have done the trick."
Den Beweis dafür,daß KB2264107+ CWDIllegalInDllSearch der Grund dafür ist, sehe ich darin,daß die OutPost-Exen funktionieren,nachdem ich ein früheres Image bei welchem der Patch noch nicht installiert war auf eine separate Partition kopiert hatte...und dort funktionierte alles.
Du sagst:"
Im Notfall würde das Entfernen/Editieren (auf "0" setzen")/Anlegen der bekannten Registry-Schlüssel bzw. -Werte helfen......
und so wäre ich sehr dankbar,wenn Du mir sagen würdest, wie und was ich da genau zu tun habe,weil meine Kenntnisse damit noch überfordert sind.
Gruß,
Horst
P.S. leider sehe ich keine Möglichkeit, Dir auf diesem Weg die beiden shortCuts (Fehleranzeigen) mit
zu übersenden.
..P.S.:
von einem diesbezügl.Agnitum-UpDate kann kann ich nirgends was entdecken.
bei mir lautet die Fehlermeldung:
Nr.1.) "OUTPOSTPROINSTALL.TEMP2" ERBITTET Netzwerk-Start >Ziel: rundell32.exe
Nr.2.) Fehler: >"Runtime Error [at 160:8689].......Could not call proc.< o.k.
von einem diesbezügl.Agnitum-UpDate kann kann ich nirgends was entdecken.
bei mir lautet die Fehlermeldung:
Nr.1.) "OUTPOSTPROINSTALL.TEMP2" ERBITTET Netzwerk-Start >Ziel: rundell32.exe
Nr.2.) Fehler: >"Runtime Error [at 160:8689].......Could not call proc.< o.k.
Moin Horst,
ich kenne die relevanten EXE-Dateien nicht und kann Dir daher keine maßgescheinderte Lösung bieten, sondern Dich nur auf http://support.microsoft.com/kb/2264107 und den dort aufgezeigten, generellen Weg ("Beispiel 2" und "Beispiel 3" verweisen.
Grundsätzlich ist es am Hersteller der Software, für eine Korrektur zu sorgen. Wende Dich bitte also in jedem Fall ggf. zusätzlich an den Hersteller-Support der "zickigen" Software.
Ebenso grundsätzlich bietet eine Personal Firewall Software keine weitere Sicherheit - die Windows Firewall schützt, wie erwähnt, zuverlässig von unerwünschten Zugriffen von außen. Wenn eine auf dem System installierte Anwendung (vermeintlich oder tatsächlich) vom Admin/Benutzer unerwünscht Kontakt nach außen aufnehmen will, wird sie dies auch unter Umgehung einer Personal Firewall Software tun können - je potenziell schadhafter die Anwendung ist, umso eher. Zur vertiefenden Information, schau Dir http://www.ntsvcfg.de/linkblock.html und die dortigen Links zum Thema "B. Personal Firewalls" an.
Bye,
Freudi
P.S.:
Wenn Du keine Homepage hast, lass bitte das entsprechende Kommentar-Feld hier einfach frei/leer, trag also bitte nichts ein. Danke.
ich kenne die relevanten EXE-Dateien nicht und kann Dir daher keine maßgescheinderte Lösung bieten, sondern Dich nur auf http://support.microsoft.com/kb/2264107 und den dort aufgezeigten, generellen Weg ("Beispiel 2" und "Beispiel 3" verweisen.
Grundsätzlich ist es am Hersteller der Software, für eine Korrektur zu sorgen. Wende Dich bitte also in jedem Fall ggf. zusätzlich an den Hersteller-Support der "zickigen" Software.
Ebenso grundsätzlich bietet eine Personal Firewall Software keine weitere Sicherheit - die Windows Firewall schützt, wie erwähnt, zuverlässig von unerwünschten Zugriffen von außen. Wenn eine auf dem System installierte Anwendung (vermeintlich oder tatsächlich) vom Admin/Benutzer unerwünscht Kontakt nach außen aufnehmen will, wird sie dies auch unter Umgehung einer Personal Firewall Software tun können - je potenziell schadhafter die Anwendung ist, umso eher. Zur vertiefenden Information, schau Dir http://www.ntsvcfg.de/linkblock.html und die dortigen Links zum Thema "B. Personal Firewalls" an.
Bye,
Freudi
P.S.:
Wenn Du keine Homepage hast, lass bitte das entsprechende Kommentar-Feld hier einfach frei/leer, trag also bitte nichts ein. Danke.
Moin,
was ist denn jetzt von dieser Meldung zu halten das die Binary Planting Lücke auch exe Dateien betrifft: http://www.heise.de/security/meldung/DLL-Luecke-Jetzt-auch-mit-EXE-Dateien-1076682.html
Der WebClient Dienst ist hier eh ausgeschaltet.
was ist denn jetzt von dieser Meldung zu halten das die Binary Planting Lücke auch exe Dateien betrifft: http://www.heise.de/security/meldung/DLL-Luecke-Jetzt-auch-mit-EXE-Dateien-1076682.html
Der WebClient Dienst ist hier eh ausgeschaltet.
Moin Robert,
sorry für die Verpätung.
Lies einfach mal die Kommentare dort quer. Neben der dort üblichen hohen Dosis Trollium, findet sich auch der ein oder andere vernünftige Kommentar zur Meldung.
Von MS gibt es zumindest bislang keine öffentliche Stellungnahme, eschweigedenn eine Sicherheitsempflehlung oder ein irgendwie geartetes Update. Wer den "WebClient"-Dienst deaktiviert, ist mutmaßlich auch dieses Mal auf der sichereren Seite.
Bye,
Freudi
sorry für die Verpätung.
Lies einfach mal die Kommentare dort quer. Neben der dort üblichen hohen Dosis Trollium, findet sich auch der ein oder andere vernünftige Kommentar zur Meldung.
Von MS gibt es zumindest bislang keine öffentliche Stellungnahme, eschweigedenn eine Sicherheitsempflehlung oder ein irgendwie geartetes Update. Wer den "WebClient"-Dienst deaktiviert, ist mutmaßlich auch dieses Mal auf der sichereren Seite.
Bye,
Freudi
Offenbar hat Microsoft das am 13.07.2010 kurzzeitig über das DownloadCenter angebotene, optionale Update KB2264107 für Windows XP und für Windows 7 zwischenzeitlich zurückgezogen. Es ist [...]
Aufgenommen: 24.08.2010 11:09
Kurzbeschreibung: Sicherheitsupdate, das eine Lücke im Kernel von Windows XP schließen soll, durch die ein lokal angemeldeter Benutzer höhere Benutzerrechte erlangen kann (Elevation of [...]
Aufgenommen: 08.02.2011 19:10