Microsoft: Sicherheitsproblem betrifft zig Programme

Sicherheitslücken Nachdem wir am Freitag darüber berichteten, dass eine aktuelle Sicherheitslücke zahlreiche Programme betrifft, hat nun Microsoft in Form eines Security Advisorys ausführlich Stellung bezogen und gibt Hinweise. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Wenn es um Sicherheitsfragen und Sicherheitsprobleme geht, macht Microsoft keiner was vor. Schnell und Effektiv!
 
@Edelasos: Hier und da lässt ein Patch auf sich warten. Aber die Handlungsweise generell finde ich schnell.
Man muss ja mal ehrlich zugeben das man in der IT sich nicht wirklich immer an die MS vorgaben hält, weil jeder weiß, dass es meist suboptimal und umständlich ist.
 
@Edelasos: Na klar! Wieso ist sowas beim sicheresten BS, lt. MS überhaupt möglich?
 
@Sighol: Wo Menschen sind passieren auch Fehler :).
 
@Edelasos:ja stimmt...das sicherheitsproblem entsteht durch unsichere Programmierung. Welch bahnbrechende, schnelle und effektive Info. Also mehr fanboy geht ja wohl kaum:-) O3 re2 hat sich wenigstens das paper durchgelesen und klingt nicht so begeistert wie du.
 
@Edelasos: müssen sie auch sein, oder kennst du noch ein os dem man so leicht etwas unterschieben kann aus NICHT zertifizierten quellen. ich nenne das einen schweren os design fehler. [ergänzung:] bevor sich noch weitere dampfplauderer wie timurlenk melden ein auszug aus tec channel. "Der Bug ist deshalb so weitreichend, weil er eine Grundfunktion von Windows ausnutzt. Und zwar können sich Hacker der Art und Weise bedienen, wie das Betriebssystem Code-Bibliotheken so etwa DLL-Dateien (Dynamic Link Library) und ausführende Files (EXE und COM) lädt. Statt besagter Dateien können die betroffenen Programme angewiesen werden, Schadsoftware zu laden."
 
@OSLin: Quatschkopf. Du hast offensichtlich noch nie ernsthaft auf irgendeinem OS programmiert. Wenn Du keine Ahnung hast, dann halte doch einfach die Klappe.
 
@Timurlenk: sieht so qualifizierte antwort aus ? das ich recht habe kannst du auf verschieden seiten nachlesen. ein os sollte ein unsicheres nachladen von dlls verhindern. microsoft aber selbst setzt diese unsichere methode beim explorer ein, also wer ist da der quatschkopf. mir musst du es ja nicht glauben, aber dann lese wenigsten fachzeitschriften.
 
@OSLin: Meine Antwort war genauso qualifiziert wie Deine ursprüngliche Aussage, bevor Du später das ganze editiert hast. Heutzutage ist es sehr weit verbreitet, dass Inhalte nachgeladen werden. Dies sind meistens dynamische Bibliotheken. Unter Windows und OS/2 heißen die Dynamic Link Library, unter Unixen (incl. Linux) heißen die Shared Libary. Bei Java werden keine System-Bibliotheken verwendet, sondern alle Klassen dynamisch geladen. Neben den lokalen dynamischen Bibliotheken werden zunehmend auf allen Systemen auch Teile über das Internet nachgeladen. Wer kennt zum Beispiel nicht die Java Web Installer, die nur wenige KB groß sind, dann aber zig Megabyte nach dem Start nachladen. Ärgerlich für die Nutzer über GSM/UMTS.
 
@Timurlenk: meine ursprüngliche aussage hat sich nicht geändert nur um den beweis dass es ein os design fehler ist erweitert.
 
Also man muss hier einiges klarstellen. Die Lücke ist schon seit Februar bekannt. Gemeldet wurde sie im Februar von einer Universität namens Taeho Kwon. Es ist kein Windows Problem in sich, sondern auf schlecht programmierte Drittsoftware zurückzuführen. Bisher gibt es noch keinen einzigen bekannten Fall, wo diese Schwachstelle ausgenutzt wurde. Es ist auch nicht einfach diese Schwachstelle auszunutzen. Es zeigt sich einmal mehr, das Windows mit ihrer Versuch WHQL auszuweiten nicht grundlos voranbringen will. Denn so könnten solche Fehler bereits am Anfang ausgeschlossen werden. Lösungen die man bei MS nachlesen kann, sind sehr effektiv, aber leider ist es und wird es nicht so schnelle möglich sein, das Problem zu 100% beseitigen. Bekannte Drittsoftwarehersteller werden sicherlich in kürze Updates veröffentlichen und somit wird das Problem extrem minimiert. Dennoch wird es in Zukunft so sein, dass man vorsichtig sein sollte, von wem man etwas bezieht. Es wird schon fieberhaft daran gearbeitet, eine kleines Tool zu entwickeln, das jede Software auf den Fehler prüft und gegeben falls eine Warnung ausgibt. Erst dann wird die Sicherheit wider gewährleistet sein.
 
@Rumulus: nicht nur drittanbieter, sondern ms selbst setzt bei gewissen programmen die unsichere methode von dlls nachladen ein.
 
@OSLin: Siehe unten 06 Edit: Das Nachladen stellt ab VISTA im Internet kaum ein Problem dar, weil sich eine dll ohne die Rechte nicht in ein Verzeichnis schreiben kann. Das Problem ist nur auf Drittsoftware bzw. Installationen beschränkt, da man schon bei der Installation manchmal die nötigen Rechte vergibt.
 
@Rumulus: danke, ich kenne dieses workaround. mir ging es aber eher darum dass sich ms selbst nicht an ihre eigenen vorgaben hält.
 
@OSLin: Sry, habe in der Ziwschezit noch editiert, lese dies einmal!
 
@Edelasos: Effektiv durch Windows Zwangsvorinstallation auf PCs und Klappcomputern die maximal großflächige Sicherheitslückenverteilung unter den Käufern erreicht, ja da macht Microsoft wirklich noch niemand was vor.
 
? Wenn ich eine Datei aus einer unsicheren (oder auch vermeindlich sicheren ) Quelle öffne, kann ich die selbstverständlich mit meinen Rechten auch öffnen, wie jedes andere Programm auch. Wie soll Windows das auch unterscheiden? Habe irgendwie nicht verstanden, worin genau die Sicherheitslücke besteht....
 
@bowflow: Laut Microsoft entsteht die Sicherheitslücke durch eine unsichere Programmierweise....
 
@hjo: ... von Drittanbietern, die die Schnittstellen falsch bedienen.
 
@rallef: Von "falsch bedienen" kann eigentlich keine Rede sein.
 
Wenn Programmierer unsauber arbeiten, ist es eine Lücke in Windows?
 
@mcbit: naja beim DLL-Laden muss(te) man nie einen Pfad angeben, ergo ist das primär ein MS-"Feature", dass eben auch bösartig ausgenutzt werden kann.
 
@mcbit: Ich habe mir den MSDN-Artikel durchgelesen. Es ist eigentlich eher ein konzeptuelles Problem seitens Microsoft Windows. Die im Artikel vorgeschlagene Lösung ist nicht sonderlich praktikabel und behebt das Problem nur teilweise. Am zuverlässigsten ist da noch die Verwendung von WinSxS (wird auch im Artikel vorgeschlagen, aber nicht an erster Position).
 
Na ja, so schlimm ist der Fehler wohl kaum. Erstens muss der Angreifer die Möglichkeit haben dlls so zu platzieren dass diese sich an den Orten befinden wo das Programm nach der dll suchen wird. Dem stehen 2 Dinge gegenüber, 1. muss der Angreifer den Rechner schon vorher attackieren um die dll zu platzieren, 2. muss er die UAC umgehen (solange man das Laden von dlls im Pfad der Applikation verhindert wäre hiermit das Problem eigentlich gelöst). Zudem scheinen mir Rechte des angemeldeten Users eher unnütz zu sein denn da kann man gleich ein schädliches Programm einschleusen. Weiter sind diese Rechte unter NT 6.x so gut wie gar nicht da (normale User Level).
 
@bluefisch200: Hier und da gibt es ja Programme, die bei der Installation die Zugriffsrechte für das Anwendungsverzeichnis lockern, damit sie Einstellungen dort speichern können, wo sie nicht hingehören (eben im Anwendungsverzeichnis). Solchen Programmen eine infizierte DLL unterzuschieben, ist dann natürlich auch unter Vista/7 mit aktivierter UAC vergleichsweise einfach.
 
@TiKu: wüsste nicht dass dies Programme dürfen, sind das nicht die welche dann immer eine UAC Abfrage auslösen wenn sie starten?
 
@bluefisch200: Normalerweise haben Programme auf das Programme-Verzeichnis (und die Unterverzeichnisse) ja nur Lesezugriff. Ein Installationsprogramm kann die Rechte aber anpassen und dem Programm so auch Schreibzugriff gewähren. Die UAC-Meldung beim Programmstart hat einen anderen Grund. Sie kommt, wenn das Programm explizit mit Admin-Rechten gestartet werden will. Wenn die Rechte vom Setup angepasst wurden, kann das Programm aber auch ohne Admin-Rechte in das Anwendungsverzeichnis schreiben.
 
@TiKu: Okay, macht Sinn, schade dass das viele Entwickler immer noch nicht gelernt haben...
 
@TiKu: Mal eine ernste Frage, wie kann eine Installation die Rechte eines Verzeichnis ändern? Da müsste die die Installation ja schon Zugriff auf die Datei haben und wie kommt sie zu den Rechten? Grundsätzlich ist dies ja nur mit Adminrechte möglich, aber ohne die Zustimmung durch die UAC hat nichts Adminrechte!
 
@Rumulus: Ja, nur ein Setup bekommt ja (wenn man bei der UAC zustimmt) immer Admin-Rechte, wie sonst sollte es die Programme installiere? Und hier kann der Entwickler dann seinem Programm die Möglichkeit geben auch in die Verzeichnisse zu schreiben...
 
@bluefisch200: Genau das meine ich ja! Aber die Aussage von TiKu re:3 ist etwas widersprüchlich bezüglich der UAC! Die Rechte vergibt man per UAC und nicht das eine Installtion seine Rechte selbst anpassen kann. Dies ist ab VISTA unmöglich, nach meinem Wissen.
 
@Rumulus: Es gibt doch massenhaft Setups, die beim Start die UAC auslösen. Voilà, schon haben sie die Rechte. EDIT: Okay, war zu langsam.
 
@DON666 und Bluefisch200: Lest nochmal meinen Beitrag re:05, besonders den letzten Satz. Ich glaub zwar nach re:7 habt ihr es selbst bemerkt!
 
@Rumulus: Nein, meine Antwort ist nicht widersprüchlich. Du gibst dem Setup via UAC Admin-Rechte und das Setup kann dann die Zugriffsrechte für das Verzeichnis, in das die Anwendung installiert wird, so abändern, dass auch normale Nutzer darin schreiben können, ohne eine UAC-Meldung auszulösen.
 
@TiKu: Ich versteh dich nun besser....nur ist das Problem, dass die UAC nicht so viele Rechte vergibt, damit ein Programm z.B. die Rechte von C:/Programme ändern kann. Kannst du selbst nachprüfen, indem du von Hand versuchst die Rechte zu ändern.
 
@Rumulus: Ich kann es mangels Zeit grad nicht prüfen, aber ich bin mir sehr sicher, dass Installationsprogramme die Zugriffsrechte verbiegen können, wenn sie einmal volle Adminrechte erhalten haben. Nach C:\Programme schreiben können sie ja, warum sollten sie nicht die Zugriffsrechte für die Ordner und Dateien, die sie erstellen, ändern können?
 
@TiKu: Offensichtlich hast du mich falsch verstanden. Es geht nicht für den Ordner Programme. Natürlich kann UAC, darum kommt sie auch, für den Installations-Ordner rechte vergeben, aber nicht darüber hinaus. UAC vergibt nie volle Admin Rechte. Ist aber ein ganz anderes Thema.
 
@Rumulus: Naja, und mehr braucht eine Anwendung doch auch nicht. Nennen wir die Anwendung xyz. UAC gibt dem Setup das Recht nach C:\Programme zu schreiben. Das Setup erstellt das Verzeichnis C:\Programme\xyz und darf selbstverständlich auch die Zugriffsrechte auf dieses Verzeichnis anpassen. Es kann z. B. dem Nutzer "Jeder" Vollzugriff gewähren. Führst du das Programm xyz dann aus, ohne ihm per UAC erweiterte Rechte zu geben, kann es dennoch nach C:\Programme\xyz schreiben, denn für dieses Verzeichnis hat das Setup ja die Zugriffsrechte entsprechend eingestellt. Ein Angreifer hat es dadurch auch leichter, eine modifizierte DLL in C:\Programme\xyz zu platzieren und somit die von Microsoft beschriebene Sicherheitslücke auszunutzen.
 
Ich als IT Sicherheitsexperte, habe dieses Problem in meiner Firma schon lange behoben.
Geht es um Sicherheitsfragen bin ich einfach hart!
 
@Xorith:
Als Sicherheitsexperte ist dir nicht in den Sinn gekommen vor "langer" Zeit, MS darüber zu informieren? Gut, dass wir nicht in der gleichen Firma arbeiten :D
 
@Xorith: Ich als IT-Sicherheitsexperte glaube dir kein Wort. Da bin ich einfach hart.
 
@Xorith: Na klar, nur kannst du das gar nicht! Nur minimieren, aber nicht beheben.
 
@Rumulus: sicher kann ich das, ich habe extended prgramming skills
 
@Xorith: Ui, Respekt! Na dann...
 
@Rumulus: Wieso soll man das nicht selbst BEHEBEN können?
 
@desire: Weil man dann die Software von Dritten umprogrammieren müsste. Es ist ja kein Systemfehler, sondern ein Anwendungsfehler durch schlechte Programmierung. Angeblich hat MS diesen Fehler selber auch im Explorer gemacht (naja, niemand ist perfekt), also müsstest Du den Explorer-Programmcode ändern um diesen Fehler zu beheben. Das ist schwerlich für Dich machbar. Du kannst natürlich den Fehler in Deinen eigenen Programmen beheben.
 
Wenn ihr aus dem Internet sicher gehen wollt, dass dieses Problem keine Wirkung hat, könnt ihr folgendes tun. Zuerst deaktiviere den Dienst "WebClient". Danach öffne die Registry und gehe zu folgendem Wert : HKLM\SYSTEM\CurrentControlSet\Control\Session Manager und klicken mit der rechten Maustaste auf Session Manager, wählen "Neu" und danach "DWORD-Wert". Gebe CWDIllegalInDllSearch ein und klicken Sie anschließend auf "Ändern". Gebe in das Feld "Wert" den Datenwert "1" ein, und klicken Sie auf OK. Danach OS Neustarten. Somit werden keine DLL mehr nachgeladen.
 
Hallo zusammen,
siehe http://bit.ly/bY27pg - dort ist es ausführlich beschrieben, was Entwickler diesbzüglich beachten sollten. (Siehe auch MSDN Box hier auf der rechten Seiten, Security Tipps, erster Eintrag).
Viele Grüße,
Kye
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles