Hi,
ich sage es gleich vorneweg: Ich bin kein Programmierer.
Insofern verstehe ich nicht, wie man diese 'Lücke' abschaffen kann, wenn schon alleine das Suchen nach einer DLL dem Schädling es ermöglicht sich einzunisten?
Es wird ja wohl niemand erwarten können, dass jedes Programm alle DLL's selber mitbringt, die es benötigt und dann in das eigene Programmverzeichnis schreibt. Auch wenn die HDD's inzwischen TByte - Größe erreicht haben.
Womit ja im Grunde auch nichts gewonnen würde. Denn das Programm 'sucht' ja dann in diesem Verzeichnis nach den DLL's....und alleine das Suchen nach DLL's soll ja schon der schlecht sein!?!?!?!?
Gruß
Ralph_H
1. Wenn man es schafft eine DLL in ein LOKALES Arbeitsverzeichnis zu platzieren, hat man bereits eine Sicherheitslücke ausgenutzt. Wieso dann noch Binary Planting nutzen?
2. Fehlende DLLs müssen auch erst platziert werden, also verweise ich auf den 2. Teil von Punkt 1.
Grüße vom Planeten Deviluke!
Ralph_H schrieb:
--------------------------------------------------------------------------------
> Insofern verstehe ich nicht, wie man diese 'Lücke' abschaffen kann, wenn
> schon alleine das Suchen nach einer DLL dem Schädling es ermöglicht sich
> einzunisten?
Es geht ja darum, *wo* eine DLL gesucht wird. Eine IMHO recht einfach Lösung wäre, dass eine DLL nur in fest definierten Pfaden (nämlich dem Betriebssystemverzeichnis, dem Installationsverzeichnis des Programms sowie einem Verzeichnis für gemeinsam verwendete DLLs) gesucht werden darf, *es sei denn*, dass das Programm selbst gezielt noch einen anderen Pfad vorsieht.
> Es wird ja wohl niemand erwarten können, dass jedes Programm alle DLL's
> selber mitbringt, die es benötigt und dann in das eigene
> Programmverzeichnis schreibt. Auch wenn die HDD's inzwischen TByte - Größe
> erreicht haben.
Erwartet ja auch niemand.
Gruß
Tantalus
___________________________
Man sollte sich die Ruhe und Nervenstärke eines Stuhles zulegen. Der muss auch mit jedem Arsch klarkommen.
Unix hat dieses uralte Problem dadurch gelöst, indem das Arbeitsverzeichnis erst gar nicht in den Suchpfad mit aufgenommen wird. Unter Windows mit seinen Altlasten lässt sich das anscheinend nur durch vorsichtigere Programmierung lösen, also umgehen aber nicht beheben, denn die Wurzel des Übels steckt immer noch in Windows selbst.
Deviluke:
Es braucht kein lokales Arbeitsverzeichnis, remote auf nem WebDAV oder SMB-Share reicht schon vollkommen aus.
Schau dir mal das hier an, ne Powerpoint-Präsentation via WebDAV:
http://www.offensive-security.com/offsec/microsoftdll-hijacking-exploit-in-action
Die Krux ist doch offensichtlich, dass _AUCH_ im Arbeitsverzeichnis (=CurrentDirectory) nach Biobliotheken gesucht wird. Dieses Arbeitsverzeichnis ist übrigend standardmäßig der Profilordner des Benutzers. Was da eine .dll zu suchen hat ist mir nicht so ganz klar.
Hier nochmal der Link, da hat noch ein Bindestrich gefehlt:
http://www.offensive-security.com/offsec/microsoft-dll-hijacking-exploit-in-action/
Da wären wir wieder am Anfang. Der Anwender muss verleitet werden ein WebShare zu öffnen. Warum sieht man die DLL nicht? Wurde sie mit einem HIDDEN-Flag versehen?
Das heißt ich brauche nur darauf achten, dass ich vertrauenswürdige Shares öffne und welche, die ich nicht kenne oder nicht vertraue nicht oder unter Linux.
Grüße vom Planeten Deviluke!
idee12345 schrieb:
--------------------------------------------------------------------------------
> Die Krux ist doch offensichtlich, dass _AUCH_ im Arbeitsverzeichnis
> (=CurrentDirectory) nach Biobliotheken gesucht wird.
Was ein Designfehler von Windows ist, außer mir kann jemand eine wirklich sinnvolles Anwendungsszenario nennen, wo so was Sinn machen würde. Ich sehe keines. Andere Betriebssysteme haben doch auch nicht derartige Probleme. In den meisten anderen Betriebssystemen läuft das ganze so ab:
1. Es gibt genau definierte Suchpfade, wo das System nach Libraries sucht, wenn ein Programm eine Library ohne Pfad lädt.
2. Lädt das System eine Library mit Pfad, dann wird diese nur an diesem Pfad gesucht, egal ob dieser absolut oder relativ ist (wobei bei einem relativen Pfad wird dieser vielleicht auch versuchsweise an die Suchpfadeinträge angehängt, da bin ich mir nicht sicher).
3. Zur Laufzeit kann ein Programm dieses Suchpfad dann selber ändern, was sich auf alle zukünftigen Ladeoperationen auswirkt, wenn das Programm später dynamisch Libraries nachladen sollte (sofern es das nicht mit absoluten Pfad macht, wo die Suchpfade eh wieder nicht zum tragen kommen).
Keine Ahnung ob das in Windows auch so ist. Aber wichtig ist natürlich das der Default Suchpfad sinnvoll gesetzt ist. D.h. er sollte die systemtypischen Library Pfade enthalten (in UNIX z.B. /lib, /usr/lib... vielleicht noch /usr/local/lib) und als Fallback höchstens noch das Verzeichnis, in dem die gestartete App selber liegt, damit ich eine App irgendwo bei mir z.B. in mein Home legen und starten kann (zusammen mit den benötigten Libraries). Abgesehen davon kann man unter UNIX/Linux diesen Suchpfad in der Regel von Hand so setzen, wie man mag als Nutzer.
Das aktuelle Working Directory hat in der Regel in keinem Suchpfad etwas zu suchen. Weder in dem für Libraries noch in dem für Befehle auf der Kommandozeile oder so.
/Mecki
Hallo,
Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Das heißt ich brauche nur darauf achten, dass ich vertrauenswürdige Shares
> öffne und welche, die ich nicht kenne oder nicht vertraue nicht oder unter
> Linux.
Was ist denn vertrauenswürdig? Ein Kollege, den man gut kennt, der sowas weiterleitet? Vielleicht der Vorgesetzte mit Auftrag? Niemand garantiert einem, dass eine eigentlich vertrauenswürdige Quelle nicht schon erwischt wurde.
gruß
-Andy (Golem.de)
Was aber effektiv hilft: Entweder nach der DLL gucken, oder per STRG-A alle sichtbaren Dateien (wenn man keine DLL sieht) kopieren und lokal öffnen.
Zusätzlich habe ich den REG-Key mit dem Wert 0xFFFFFFFF erstellt.
Grüße vom Planeten Deviluke!
Hast du auch den Patch installiert? Der Regeintrag alleine ist unwirksam.
Ja, habe ich. :)
Grüße vom Planeten Deviluke!
1 mal bearbeitet, zuletzt am 27.08.10 11:01 durch Lala Satalin Deviluke.
Sehr schön ;)
Daheim unter Windows 7 und hier auf der Arbeit unter XP SP3 isser auch schon installiert. Bis jetzt gibts nur mit Google Chrome Probleme...
Bei mir läuft Chrome auf XP SP3 einwandfrei mit dem Patch.
Grüße vom Planeten Deviluke!
Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Was aber effektiv hilft: Entweder nach der DLL gucken, oder per STRG-A alle
> sichtbaren Dateien (wenn man keine DLL sieht) kopieren und lokal öffnen.
>
> Zusätzlich habe ich den REG-Key mit dem Wert 0xFFFFFFFF erstellt.
Nö - das hilft nicht. Gibt ein nettes Beispiel auf youtube - da haben die den WebDav Server so manipuliert das er einfach nach einer Anfrage nach der dll-Datei die verseuchte zurück liefert.
http://www.youtube.com/watch?v=UdCxh1uNot0
Also was hilft! 1. Alle Dateien vom WebDav kopieren auf ein lokales Laufwerk - dann alle vorhandenen ausführbaren Dateien und auf jeden Fall die .dlls löschen und danach das Dokument öffnen.
Auf WEbDAV bin ich eh nie unterwegs. Und solche YT-Videos sind keine vertrauenswürdige Quelle. Kann alles manipuliert sein.
Grüße vom Planeten Deviluke!
/mecki78 schrieb:
--------------------------------------------------------------------------------
> idee12345 schrieb:
> ---------------------------------------------------------------------------
> -----
> > Die Krux ist doch offensichtlich, dass _AUCH_ im Arbeitsverzeichnis
> > (=CurrentDirectory) nach Biobliotheken gesucht wird.
>
> Was ein Designfehler von Windows ist, außer mir kann jemand eine wirklich
> sinnvolles Anwendungsszenario nennen, wo so was Sinn machen würde. Ich sehe
> keines.
Portable Apps, auf einem USB-Stick ?
Kommentare: 170 | letzter Beitrag 15:54 Uhr
Kommentare: 94 | letzter Beitrag 26.05. 19:45
Kommentare: 68 | letzter Beitrag 14:48 Uhr
Kommentare: 64 | letzter Beitrag 26.05. 17:51
Kommentare: 60 | letzter Beitrag 26.05. 13:16
E-Mail an news@golem.de
Ein soziales Netzwerk für Pornografie muss seine Marke nicht an Facebook übergeben. Faceporn, ein norwegisches Unternehmen, freut sich über den Sieg vor einem kalifornischen Gericht.
Diablo 3 ist toll, sagen viele Spieler - Diablo 3 ist eine Stimulus-Response-Maschine, sagt Rainer Sigl. Der Blogger und leidenschaftliche Gamer erklärt, warum er sich Blizzards jüngstem Werk verweigert.
Lockheed Martin hat eine neue Version des Exoskeletts Hulc vorgestellt, das es einem Menschen ermöglicht, schwere Lasten zu heben und zu tragen. Der Hersteller will das System im Spätsommer testen und, wenn alles gutgeht, danach an US-Soldaten in Afghanistan ausliefern.
Renesas ist nach Elpida der zweite schwer angeschlagene japanische Chiphersteller. Renesas, das Hitachi, Mitsubishi Electric und NEC gehört, macht Verlust und will seine größte Fabrik verkaufen.
RIM soll in den kommenden Tagen erneut einen massiven Stellenabbau ankündigen. "Ich habe herausgefunden, welche Teile ich in meinem Puzzle nicht mehr benötige", sagte Firmenchef Thorsten Heins.
Ein britisches Blog will erfahren haben, dass Facebook den norwegischen Browserhersteller Opera Software kaufen will. Beide Unternehmen wollen sich dazu nicht äußern.